From owner-multi6@ops.ietf.org Tue Dec 4 15:38:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11462 for ; Tue, 4 Dec 2001 15:38:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16BMFn-000Mq9-00 for multi6-data@psg.com; Tue, 04 Dec 2001 12:33:23 -0800 Received: from e23.nc.us.ibm.com ([32.97.136.229]) by psg.com with esmtp (Exim 3.33 #1) id 16BMFm-000Mq3-00 for multi6@ops.ietf.org; Tue, 04 Dec 2001 12:33:22 -0800 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e23.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA71374; Tue, 4 Dec 2001 14:30:08 -0600 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.21.26]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fB4KWcp39978; Tue, 4 Dec 2001 15:32:38 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id fB4KWR201330; Tue, 4 Dec 2001 15:32:28 -0500 Message-Id: <200112042032.fB4KWR201330@rotala.raleigh.ibm.com> To: "Michel Py" cc: multi6@ops.ietf.org, smd@ebone.net Subject: Re: (multi6) Salt Lake meeting agenda In-Reply-To: Message from "Wed, 21 Nov 2001 16:41:49 PST." <2B81403386729140A3A899A8B39B046403AF26@server2000.arneill-py.sacramento.ca.us> Date: Tue, 04 Dec 2001 15:32:27 -0500 From: Thomas Narten Sender: owner-multi6@ops.ietf.org Precedence: bulk > I would like a small slot during the Salt Lake meeting to discuss issues > with draft-multi6-py-mhtp-01.txt I assume you mean draft-py-multi6-mhtp-01.txt, which is now out. The chairs tend to believe that presentations on solutions are premature until we complete the requirements drafts. We also have a one-hour slot in SLC, which wouldn't allow much time for detailed discussions on proposals. At this point, we believe we should focus on getting the following documents out of the WG: draft-ietf-multi6-multihoming-requirements-02.txt draft-ietf-multi6-v4-multihoming-00.txt There has been a fair amount of recent discussion on the requirements document, but none on the ID that was submitted. Is this one ready for WG Last Call? I'd like to see everyone read it for Salt Lake City and all remaining issues out on the table. FYI, I also count the following documents that are related to the multi6 effort: draft-py-multi6-mhtp-01.txt draft-bagnulo-multi6-survey6-00.txt draft-huitema-multi6-hosts-00.txt draft-ramki-multi6-nlmp-00.txt draft-hain-ipv6-pi-addr-01.txt draft-hain-ipv6-pi-addr-use-01.txt Thomas From owner-multi6@ops.ietf.org Tue Dec 4 16:39:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13519 for ; Tue, 4 Dec 2001 16:39:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16BNFL-000PGQ-00 for multi6-data@psg.com; Tue, 04 Dec 2001 13:36: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 16BNFK-000PGK-00 for multi6@ops.ietf.org; Tue, 04 Dec 2001 13:36:58 -0800 Subject: RE: (multi6) Salt Lake meeting agenda Date: Tue, 4 Dec 2001 13:36:53 -0800 Message-ID: <2B81403386729140A3A899A8B39B046403AF4C@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Thread-Topic: (multi6) Salt Lake meeting agenda Thread-Index: AcF9Awxb1TISQ9e4S0uID/2xuRIZbAAALjlw From: "Michel Py" To: "Thomas Narten" content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 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 QAA13519 Thomas and multi6 folk, >> There has been a fair amount of recent discussion on the requirements >> document, but none on the ID that was submitted. I believe it is because, thanks to Joe, we had a preview of what was being submitted and discussed the preview and not the actual submission. >> Is this one ready for WG Last Call? I'd like to see everyone read it for >> Salt Lake City and all remaining issues out on the table. I think that draft-ietf-multi6-multihoming-requirements-02.txt is ready for WG Last Call. IMHO there are two points where semantics could be debated, 3.1.4 Policy (that has been debated a while ago) and 3.2.6 Cooperation where I think we need a clear definition of the word "cooperation". >> FYI, I also count the following documents that are related to the >> multi6 effort: >> draft-py-multi6-mhtp-01.txt >> draft-bagnulo-multi6-survey6-00.txt >> draft-huitema-multi6-hosts-00.txt >> draft-ramki-multi6-nlmp-00.txt >> draft-hain-ipv6-pi-addr-01.txt >> draft-hain-ipv6-pi-addr-use-01.txt I have included a section "compliance with the requirements" in my own text, and Christian did something similar in his. I encourage authors of solutions drafts to do the same. Michel From owner-multi6@ops.ietf.org Fri Dec 7 14:09:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28031 for ; Fri, 7 Dec 2001 14:09:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16CQIk-000AZI-00 for multi6-data@psg.com; Fri, 07 Dec 2001 11:04:50 -0800 Received: from e21.nc.us.ibm.com ([32.97.136.227]) by psg.com with esmtp (Exim 3.33 #1) id 16CQIj-000AZC-00 for multi6@ops.ietf.org; Fri, 07 Dec 2001 11:04:49 -0800 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA36490 for ; Fri, 7 Dec 2001 13:01:28 -0600 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.21.26]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fB7J4ht221918 for ; Fri, 7 Dec 2001 14:04:43 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id fB7J4Lc02969 for ; Fri, 7 Dec 2001 14:04:21 -0500 Message-Id: <200112071904.fB7J4Lc02969@rotala.raleigh.ibm.com> To: multi6@ops.ietf.org Subject: Multi6 agenda for for Salt Lake City Date: Fri, 07 Dec 2001 14:04:21 -0500 From: Thomas Narten Sender: owner-multi6@ops.ietf.org Precedence: bulk Folks, I've appended the proposed agenda for Salt Lake City. It has the two WG documents on it for discussion: draft-ietf-multi6-multihoming-requirements-02.txt draft-ietf-multi6-v4-multihoming-00.txt None of the draft authors will be in Salt Lake City, and the current plan is to have the chairs lead discussion on open issues. By my take, there are no major open issues with the requirements document. If none are raised on the list (or in the meeting), discussion will presumably be brief. At this point, I'm told that we are close to being ready for WG Last Call. The v4-multihoming document needs some revisions, and my understaning is the authors are waiting text from others. If you have issues with that document, please bring them up on the list (or in the meeting). We may have a short meeting. Thomas Site Multihoming in IPv6 (multi6) Chair(s): Sean Doran Thomas Narten What: Meeting in Salt Lake City When: Tuesday Afternoon II (1 hour) Intro (5 min) draft-ietf-multi6-multihoming-requirements-02.txt (Narten/Doran) draft-ietf-multi6-v4-multihoming-00.txt (Narten/Doran) Wrapup (5 min) Related IDs, but ones that are not currently WG documents, pending finishing the documents in our charter: draft-py-multi6-mhtp-01.txt draft-bagnulo-multi6-survey6-00.txt draft-huitema-multi6-hosts-00.txt draft-ramki-multi6-nlmp-00.txt draft-hain-ipv6-pi-addr-01.txt draft-hain-ipv6-pi-addr-use-01.txt draft-ohta-e2e-multihoming-02.txt draft-teraoka-ipng-lin6-01.txt draft-berkowitz-multireq-02.txt From owner-multi6@ops.ietf.org Tue Dec 11 17:08:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25906 for ; Tue, 11 Dec 2001 17:08:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Dv1B-0009Ax-00 for multi6-data@psg.com; Tue, 11 Dec 2001 14:04:53 -0800 Received: from sommerfeld.ne.mediaone.net ([66.31.126.43] helo=stack.hamachi.org) by psg.com with esmtp (Exim 3.33 #1) id 16Dv1A-0009Aq-00 for multi6@ops.ietf.org; Tue, 11 Dec 2001 14:04:52 -0800 Received: from syn.hamachi.org (orchard.hamachi.org [18.101.2.2]) by stack.hamachi.org (Postfix) with ESMTP id 7FF0C26CF for ; Tue, 11 Dec 2001 17:04:46 -0500 (EST) Received: from syn (localhost [[UNIX: localhost]]) by syn.hamachi.org (8.11.6/8.8.8) with ESMTP id fBBLw4E00335 for ; Tue, 11 Dec 2001 16:58:04 -0500 (EST) Message-Id: <200112112158.fBBLw4E00335@syn.hamachi.org> From: Bill Sommerfeld To: multi6@ops.ietf.org Subject: requirements draft comments. Reply-To: sommerfeld@orchard.arlington.ma.us Date: Tue, 11 Dec 2001 16:57:59 -0500 Sender: owner-multi6@ops.ietf.org Precedence: bulk I took a look at the requirements draft; section 3.1.3 says in part: 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. This is very strong (lots of MUSTs, and "none") but is also vague -- what does "in normal operation" mean.. i.e., are transient failures a "normal" part of internet operation? "E" is just a customer and so most likely has no control over how T1 and T2 operate their networks; accordingly, "ensure" seems too strong a word to use.. How quickly must the multihoming system respond to attempts to ensure separation of traffic? minutes? hours? days? is it okay to require manual intervention from folks at T1 and T2? section 3.2.3 "impact on hosts": It would be compatible with this requirement for such a host to lose connectivity if a site lost connectivity to one transit provider, despite the fact that other transit provider connections were still operational. I can read this either as allowing loss of connectivity to hosts at external sites, or as allowing total loss of connectivity, including to other hosts within the site. Which was intended? - Bill From owner-multi6@ops.ietf.org Tue Dec 11 23:06:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03504 for ; Tue, 11 Dec 2001 23:06:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16E0dh-0002Ho-00 for multi6-data@psg.com; Tue, 11 Dec 2001 20:05:01 -0800 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.33 #1) id 16E0dg-0002He-00 for multi6@ops.ietf.org; Tue, 11 Dec 2001 20:05:00 -0800 Received: (qmail 33358 invoked by uid 1000); 12 Dec 2001 04:04:58 -0000 Date: Tue, 11 Dec 2001 23:04:58 -0500 From: Joe Abley To: Bill Sommerfeld Cc: multi6@ops.ietf.org Subject: Re: requirements draft comments. Message-ID: <20011211230458.P26079@buffoon.automagic.org> References: <200112112158.fBBLw4E00335@syn.hamachi.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200112112158.fBBLw4E00335@syn.hamachi.org> User-Agent: Mutt/1.3.22.1i Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, Dec 11, 2001 at 04:57:59PM -0500, Bill Sommerfeld wrote: > I took a look at the requirements draft; section 3.1.3 says in part: > > 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. > > This is very strong (lots of MUSTs, and "none") but is also vague -- > what does "in normal operation" mean.. i.e., are transient failures a > "normal" part of internet operation? "In normal operation" means "most of the time, when there are no topological failure conditions". For example, if the circuit between E and T2 was down, you would expect traffic from T2 to E to traverse T1. That would not be "normal operation". > "E" is just a customer and so most likely has no control over how T1 > and T2 operate their networks; accordingly, "ensure" seems too strong > a word to use.. In the IPv4 world, E is a customer and has control over the network policies of T1 and T2 by virtue of that fact. E can be fairly sure that T1 should prefer routes learnt from E over the same routes learnt via T2, since there are good reasons to localpref customer routes above peer routes. As is commonly used in IPv4 today, so must we provide in IPv6, else people will attempt to do the IPv4 hacks in v6 and we will not have changed much. > How quickly must the multihoming system respond to attempts to ensure > separation of traffic? minutes? hours? days? is it okay to require > manual intervention from folks at T1 and T2? I think it's ok not to specify that. The fact that the process MAY be manual should imply that the requirement is for the facility to be there, rather than the facility to exhibit a constrainted set of characteristics. > section 3.2.3 "impact on hosts": > > It would be compatible with this requirement for such a host to lose > connectivity if a site lost connectivity to one transit provider, > despite the fact that other transit provider connections were still > operational. > > I can read this either as allowing loss of connectivity to hosts at > external sites, or as allowing total loss of connectivity, including > to other hosts within the site. Which was intended? Either or both, I think. But realistically, probably more likely the former. Joe From owner-multi6@ops.ietf.org Wed Dec 12 10:28:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09084 for ; Wed, 12 Dec 2001 10:28:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16EBHg-000MNL-00 for multi6-data@psg.com; Wed, 12 Dec 2001 07:27:00 -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 16EBHf-000MND-00 for multi6@ops.ietf.org; Wed, 12 Dec 2001 07:27:00 -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 QAA10626; Wed, 12 Dec 2001 16:26:50 +0100 Received: from gsine04.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA46358 from ; Wed, 12 Dec 2001 16:26:45 +0100 Message-Id: <3C177732.74CC1541@hursley.ibm.com> Date: Wed, 12 Dec 2001 16:26: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: Joe Abley Cc: Bill Sommerfeld , multi6@ops.ietf.org Subject: Re: requirements draft comments. References: <200112112158.fBBLw4E00335@syn.hamachi.org> <20011211230458.P26079@buffoon.automagic.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Joe Abley wrote: > > On Tue, Dec 11, 2001 at 04:57:59PM -0500, Bill Sommerfeld wrote: ... > > section 3.2.3 "impact on hosts": > > > > It would be compatible with this requirement for such a host to lose > > connectivity if a site lost connectivity to one transit provider, > > despite the fact that other transit provider connections were still > > operational. > > > > I can read this either as allowing loss of connectivity to hosts at > > external sites, or as allowing total loss of connectivity, including > > to other hosts within the site. Which was intended? > > Either or both, I think. But realistically, probably more likely the > former. I agree (as the original author of these words). I don't think we can set the bar any higher; the idea is only that legacy hosts can continue to operate when everything is normal. Brian From owner-multi6@ops.ietf.org Mon Dec 17 14:45:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16273 for ; Mon, 17 Dec 2001 14:45:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16G3eq-000GJM-00 for multi6-data@psg.com; Mon, 17 Dec 2001 11:42:40 -0800 Received: from evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net ([4.60.69.141] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.33 #1) id 16G3ep-000GJG-00 for multi6@ops.ietf.org; Mon, 17 Dec 2001 11:42:39 -0800 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Mon, 17 Dec 2001 11:42:33 -0800 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 4B3BF8FDC2B64B94BB355370D406A8A7 for plus 1 more; Mon, 17 Dec 2001 11:42:32 -0800 From: "Tony Hain" To: , Subject: RE: requirements draft comments. Date: Mon, 17 Dec 2001 11:39:57 -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) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <200112112158.fBBLw4E00335@syn.hamachi.org> X-SLUIDL: 4117A74B-7C1146A9-B93DCDDC-38585478 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Bill Sommerfeld wrote: > This is very strong (lots of MUSTs, and "none") but is also vague -- I agree, the tone is over the top in many places, and very IPv4 centric. I believe the intent is that the technical approach allow for specific capabilities, though policy may not. In any case it the full set of MUSTs are applied to a single site or service provider set, the result is not operationally viable. 3.1.2 By multihoming, a site MUST be able to distribute both inbound and outbound traffic between multiple transit providers. This requirement is for concurrent use of the multiple transit providers, not just the usage of one provider over one interval of time and another provider over a different interval. The outbound case is local policy within the site, and has nothing to do with a global multihoming routing architecture. For the inbound case, a site only has as much control as their policy aligns with the remote site. For example: SiteA and SiteB are each attached to both ISPc and ISPd. It is SiteA's policy to direct inbound traffic through ISPc, but it is SiteB's policy to send everything to ISPd, and ISPd's policy to deliver bits over the direct connection rather than through another ISP. Since the holder of the traffic wins, there is no way a multihoming technology can assure that SiteA will achieve the MUST written here. 3.1.3 para 3: A multi-homed site MUST be able to distribute inbound traffic from particular multiple transit providers according to the particular address range within their site which is sourcing or sinking the traffic. As I read that every provider MUST accept my *subnet* ranges into their routing because I as a customer have more control over where my traffic goes than the service provider does. I suspect the intent was focused on IPv4 prefix, but it says address range rather than prefix so how should that be interpreted? 3.1.4 A new IPv6 multihoming proposal MUST provide support for site-multihoming for external policy reasons. This is vague. The example is focused on applications that use a well known port, but the requirement does not say that route policy be based on ports. Doing so would clearly be broken, and since people do this by selecting address ranges for those applications today, why is an IPv6 solution expected to be any different? 3.1.5 The current multihoming solution is quite straightforward to deploy and maintain. Absolute BS. If it were simple there would be many more people that understood it, and the salary range of the routing geeks would be much lower. A new IPv6 multihoming proposal MUST NOT be substantially more complex to deploy and operate than current IPv4 multihoming practices. I think everyone would agree with this. 3.1.6 Multihoming solutions MUST provide re-homing transparency for transport-layer sessions; i.e. exchange of data between devices on the multihomed site and devices elsewhere on the Internet may proceed with no greater interruption than that associated with the transient packet loss during the re-homing event. This appears to be requiring provider independence, since that is the only way to do this today. New transport-layer sessions MUST be able to be created following a re-homing event. This can't be assured if there are filters in the path that only allowed the original address range through. Does this requirement mandate that addresses don't change on the host, or is something else like NAT expected? Transport-layer sessions include those involving transport-layer protocols such as TCP, UDP and SCTP over IP. Applications which communicate over raw IP and other network-layer protocols MAY also enjoy re-homing transparency. This appears to be mandating mobile-IP since that is the only way to do this today if the site prefix changes. 3.2.1 A new IPv6 multihoming architecture MUST scale to accommodate orders of magnitude more multi-homed sites without imposing unreasonable requirements on the routing system. What is unreasonable? Is it unreasonable that we don't do garbage collection on IPv4 allocations because it is too hard to renumber? Is it unreasonable that we don't allocate for expected growth today, but historically allocated well beyond what might ever be necessary? Clearly there is some middle ground between those which would help the problem today, but this vague comment gives no guidance on what a IPv6 approach should do. In draft-hain-ipv6-pi-addr-use-01.txt I suggest that 4 prefixes per AS is a managable number which captures ~80% of the existing ASs, but I am open on the actual number. If we are setting requirements here, this is one item that should be specified if nothing more than an upper bound. 3.2.3 If the solution requires changes to the host stack, these changes MUST be either minor, or in the form of logically separate functions added to existing functions. Is it considered minor that a host implementation has the brain-dead bug of only allowing 001 for global prefixes? 3.2.4 The solution MAY involve interaction between a site's hosts and its routing system; such an interaction MUST be simple, scaleable and securable. As they say, pick any 2 because you can't afford all 3. A better choice of wording might be: an interaction must address the issues of simplicity, scalability, and security. 3.2.5 It MUST be posssible for staff responsible for the operation of a site to monitor and configure the site's multihoming system. Even if they can't configure their external routing today? I assume you mean it should be no more complex to manage and monitor their multihoming solution than any existing external routing. Tony From owner-multi6@ops.ietf.org Mon Dec 17 15:31:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17407 for ; Mon, 17 Dec 2001 15:31:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16G4MO-000Gvv-00 for multi6-data@psg.com; Mon, 17 Dec 2001 12:27:40 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16G4MN-000Gvn-00 for multi6@ops.ietf.org; Mon, 17 Dec 2001 12:27:39 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16G4Lt-0003CW-00; Mon, 17 Dec 2001 12:27:09 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Tony Hain" Cc: , Subject: RE: requirements draft comments. References: <200112112158.fBBLw4E00335@syn.hamachi.org> Message-Id: Date: Mon, 17 Dec 2001 12:27:09 -0800 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > 3.1.2 > By multihoming, a site MUST be able to distribute both inbound and > outbound traffic between multiple transit providers. This > requirement is for concurrent use of the multiple transit providers, > not just the usage of one provider over one interval of time and > another provider over a different interval. > > The outbound case is local policy within the site, and has nothing to do > with a global multihoming routing architecture. this presumes that the architecture does not impose or negotiate outbound policy at the border between a site and the more global network, and i don't smell that this wg has made that decision yet. and, in order for the site to make outbound decisions, the site or its components which make such decisions need the routing information on which to base such decisions, even using christian's ping as a routing protocol. randy From owner-multi6@ops.ietf.org Mon Dec 17 15:48:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17847 for ; Mon, 17 Dec 2001 15:48:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16G4dF-000HCb-00 for multi6-data@psg.com; Mon, 17 Dec 2001 12:45:05 -0800 Received: from evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net ([4.60.69.141] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.33 #1) id 16G4dD-000HCL-00; Mon, 17 Dec 2001 12:45:04 -0800 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Mon, 17 Dec 2001 12:45:02 -0800 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id D6267136BAB54769AA461ED88082CF30 for plus 2 more; Mon, 17 Dec 2001 12:45:01 -0800 From: "Tony Hain" To: "Randy Bush" Cc: , Subject: RE: requirements draft comments. Date: Mon, 17 Dec 2001 12:42:23 -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) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: X-SLUIDL: 82A64F48-37AD4416-8DD986E9-8BE4CEBD Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Randy Bush wrote: > this presumes that the architecture does not impose or > negotiate outbound > policy at the border between a site and the more global > network, and i don't > smell that this wg has made that decision yet. If the group wants to invent policy negotiation protocols, they will be explicitly breaking the requirement in 3.1.5 to make sure the solution is no more complex than today. Even if the protocol were simple, the ops staff would not be up to the task of interpreting the dynamic results. > and, in order for the site to make outbound decisions, the site or its > components which make such decisions need the routing > information on which > to base such decisions, even using christian's ping as a > routing protocol. Using the example I sent before; SiteB has a policy based on cost that if the interface to ISPd is up, default all outbound traffic there. What routing information does SiteB need beyond the first hop? Tony From owner-multi6@ops.ietf.org Mon Dec 17 15:58:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18035 for ; Mon, 17 Dec 2001 15:58:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16G4m8-000HKM-00 for multi6-data@psg.com; Mon, 17 Dec 2001 12:54:16 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16G4m7-000HKG-00 for multi6@ops.ietf.org; Mon, 17 Dec 2001 12:54:15 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16G4m6-0003wH-00; Mon, 17 Dec 2001 12:54:14 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Tony Hain Cc: multi6@ops.ietf.org Subject: RE: requirements draft comments. References: Message-Id: Date: Mon, 17 Dec 2001 12:54:14 -0800 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> this presumes that the architecture does not impose or negotiate outbound >> policy at the border between a site and the more global network, and i >> don't smell that this wg has made that decision yet. > If the group wants to invent policy negotiation protocols, they will be > explicitly breaking the requirement in 3.1.5 to make sure the solution > is no more complex than today. i guess you have not been tracking drafts in the idr wg >> and, in order for the site to make outbound decisions, the site or its >> components which make such decisions need the routing information on >> which to base such decisions, even using christian's ping as a routing >> protocol. > Using the example I sent before; SiteB has a policy based on cost that > if the interface to ISPd is up, default all outbound traffic there. for a non-trivial but useful set of folk, ISPd may not be able to take traffic to all destinations. there are significant sites which peer with a few folk and buy transit from others. sometimes they both peer and transit another network, with separate contracts and maybe separate connections. randy From owner-multi6@ops.ietf.org Mon Dec 17 16:07:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18291 for ; Mon, 17 Dec 2001 16:07:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16G4xb-000HXE-00 for multi6-data@psg.com; Mon, 17 Dec 2001 13:06:07 -0800 Received: from evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net ([4.60.69.141] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.33 #1) id 16G4xa-000HX6-00; Mon, 17 Dec 2001 13:06:06 -0800 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Mon, 17 Dec 2001 13:06:04 -0800 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id E8B8D26A25F247F7B45864E83A7AD4DF for plus 1 more; Mon, 17 Dec 2001 13:06:04 -0800 From: "Tony Hain" To: "Randy Bush" Cc: Subject: RE: requirements draft comments. Date: Mon, 17 Dec 2001 13:03:24 -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) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: X-SLUIDL: 8F911EFC-70D54FEF-B7C8AED0-12D8297D Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Randy Bush wrote: > i guess you have not been tracking drafts in the idr wg There are only so many hours in a day. > for a non-trivial but useful set of folk, ISPd may not be able to take > traffic to all destinations. there are significant sites > which peer with a > few folk and buy transit from others. sometimes they both > peer and transit > another network, with separate contracts and maybe separate > connections. I was not trying to imply that more complex interconnects are out of scope, but that the requirements of the words in the current draft can't be met by the simple case when a site simply defaults to one provider when the connection is up. Either the wording needs to be softened to SHOULD, or the default case should be explicitly addressed. Tony From owner-multi6@ops.ietf.org Mon Dec 17 16:14:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18474 for ; Mon, 17 Dec 2001 16:14:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16G532-000Hcy-00 for multi6-data@psg.com; Mon, 17 Dec 2001 13:11:44 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16G531-000Hcs-00 for multi6@ops.ietf.org; Mon, 17 Dec 2001 13:11:43 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16G530-0004OS-00; Mon, 17 Dec 2001 13:11:42 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Tony Hain" Cc: Subject: RE: requirements draft comments. References: Message-Id: Date: Mon, 17 Dec 2001 13:11:42 -0800 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> i guess you have not been tracking drafts in the idr wg > There are only so many hours in a day. new stuff where filtering policy can be pushed, not that i like it > I was not trying to imply that more complex interconnects are out of > scope, but that the requirements of the words in the current draft can't > be met by the simple case when a site simply defaults to one provider > when the connection is up. Either the wording needs to be softened to > SHOULD, or the default case should be explicitly addressed. i thought the base case was load balanced, or at least load distributed randy From owner-multi6@ops.ietf.org Mon Dec 17 20:23:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22629 for ; Mon, 17 Dec 2001 20:23:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16G8x8-000LK9-00 for multi6-data@psg.com; Mon, 17 Dec 2001 17:21:54 -0800 Received: from evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net ([4.60.69.141] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.33 #1) id 16G8x8-000LJy-00 for multi6@ops.ietf.org; Mon, 17 Dec 2001 17:21:54 -0800 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Mon, 17 Dec 2001 17:21:49 -0800 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id E8F9BE47216143EDBA7CFBACD2B129C5 for plus 1 more; Mon, 17 Dec 2001 17:21:48 -0800 From: "Tony Hain" To: "Michel Py" , Subject: RE: (multi6) requirements draft comments Date: Mon, 17 Dec 2001 17:18: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) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <000001c1875a$ef0679f0$de8adacd@arneillpy.sacramento.ca.us> X-SLUIDL: AAD73662-81214E9A-9F72D5C8-5BBBD83D Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Michel Py wrote: > I think that the original intend of 3.1.2 for inbound was to prevent > flaky destination address selection schemes such as > round-robin. The way > I read it is that, if a multihomed site as multiple PA > addresses but no > PI address, the address selection algorithm to pick which of the PA > address is to be used must pick the best one for a specific source, > which probably means that the address selection must know about the > network topology, which means either a hook into BGP or some other > sophisticated mechanism yet to be defined. Having a host know the topology is the flaky scheme. DNS round-robin works fine to isolate the address selection from the topology knowledge. That section appears to be trying to describe the case that SiteA has the ability to inject a long prefix into all ISPs. My concern is that it states a site MUST be able to control traffic flow, when it is the receiver. This is technically not possible since the holder of the packet can choose any path it wants by ignoring the detailed announcement from the receiver. > There might be other ways (TCP hacks/stack hacks), but the PI address > being the one that is configured on the hosts is the only proven one. > Note that the PI address could (although I do not recommend it) be a > site-local address with NAT. The point was that the correspondent must perceive that the address didn't change, else the interruption will be more than a simple packet loss. Use of a NAT is orthogonal because the public side of the NAT has the same issue. Tony From owner-multi6@ops.ietf.org Mon Dec 17 21:18:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23441 for ; Mon, 17 Dec 2001 21:18:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16G9pX-000M9C-00 for multi6-data@psg.com; Mon, 17 Dec 2001 18:18:07 -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 16G9pW-000M95-00 for multi6@ops.ietf.org; Mon, 17 Dec 2001 18:18:07 -0800 content-class: urn:content-classes:message Subject: (multi6) requirements draft comments Date: Mon, 17 Dec 2001 18:18:06 -0800 Message-ID: <2B81403386729140A3A899A8B39B046403D5A7@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: multi6 post X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Index: AcGHW5SjnW0S+PdAR3eTLWXR+55GgAADog8A 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 VAA23441 Multi6 folk, I guess this counts towards the WG last call.... Tony Hain wrote >> 3.1.2 >> By multihoming, a site MUST be able to distribute both inbound and >> outbound traffic between multiple transit providers. This >> requirement is for concurrent use of the multiple transit providers, >> not just the usage of one provider over one interval of time and >> another provider over a different interval. >> The outbound case is local policy within the site, and has nothing to >> do with a global multihoming routing architecture. For the inbound >> case, a site only has as much control as their policy aligns with the >> remote site. For example: SiteA and SiteB are each attached to both >> ISPc and ISPd. It is SiteA's policy to direct inbound traffic through >> ISPc, but it is SiteB's policy to send everything to ISPd, and ISPd's >> policy to deliver bits over the direct connection rather than through >> another ISP. Since the holder of the traffic wins, there is no way a >> multihoming technology can assure that SiteA will achieve the MUST >> written here. I think that the original intend of 3.1.2 for inbound was to prevent flaky destination address selection schemes such as round-robin. The way I read it is that, if a multihomed site as multiple PA addresses but no PI address, the address selection algorithm to pick which of the PA address is to be used must pick the best one for a specific source, which probably means that the address selection must know about the network topology, which means either a hook into BGP or some other sophisticated mechanism yet to be defined. >> 3.1.4 >> A new IPv6 multihoming proposal MUST provide support for >> site-multihoming for external policy reasons. >> This is vague. The example is focused on applications that use a well >> known port, but the requirement does not say that route policy be >> based on ports. Doing so would clearly be broken, and since people do >> this by selecting address ranges for those applications today, why is >> an IPv6 solution expected to be any different? This is vague indeed and I would not mind dropping 3.1.4 although it does not bother me. >> 3.1.6 >> Multihoming solutions MUST provide re-homing transparency for >> transport-layer sessions; i.e. exchange of data between devices on >> the multihomed site and devices elsewhere on the Internet may proceed >> with no greater interruption than that associated with the transient >> packet loss during the re-homing event. >> This appears to be requiring provider independence, since that is the >> only way to do this today. There might be other ways (TCP hacks/stack hacks), but the PI address being the one that is configured on the hosts is the only proven one. Note that the PI address could (although I do not recommend it) be a site-local address with NAT. >> 3.2.6 Cooperation between Transit Providers >> A multihoming strategy MAY require cooperation between a site and its >> transit providers, but MUST NOT require cooperation directly between >> the transit providers. I propose to change this (from an idea originally suggested by Pekka Savola) to: 3.2.6 Cooperation between Transit Providers 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. Michel. From owner-multi6@ops.ietf.org Tue Dec 18 03:27:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15755 for ; Tue, 18 Dec 2001 03:27:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16GFZp-0004Uk-00 for multi6-data@psg.com; Tue, 18 Dec 2001 00:26:17 -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 16GFZo-0004Uc-00 for multi6@ops.ietf.org; Tue, 18 Dec 2001 00:26:16 -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 JAA04502; Tue, 18 Dec 2001 09:26:10 +0100 Received: from dhcp222-13.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA23436 from ; Tue, 18 Dec 2001 09:26:08 +0100 Message-Id: <3C1EFDA1.7C77FEA@hursley.ibm.com> Date: Tue, 18 Dec 2001 09:26:09 +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: multi6@ops.ietf.org Subject: Re: (multi6) requirements draft comments References: <2B81403386729140A3A899A8B39B046403D5A7@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 Michel Py wrote: ... > >> 3.1.4 > >> A new IPv6 multihoming proposal MUST provide support for > >> site-multihoming for external policy reasons. > >> This is vague. The example is focused on applications that use a well > > >> known port, but the requirement does not say that route policy be > >> based on ports. Doing so would clearly be broken, and since people do > > >> this by selecting address ranges for those applications today, why is > > >> an IPv6 solution expected to be any different? > > This is vague indeed and I would not mind dropping 3.1.4 although it > does not bother me. I think it needs to stay in, but the phrase "or application, NNTP, for example, " should be deleted. That would leave the "example" sentence as For example, customer C homed to ISP A may wish to shift traffic of a certain class to ISP B as matter of policy. which is necessary and sufficient IMHO. We could refine it further by saying "shift outgoing traffic" to make it clear that this is not policy based routing. Brian From owner-multi6@ops.ietf.org Tue Dec 18 03:34:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15837 for ; Tue, 18 Dec 2001 03:34:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16GFhd-0004aP-00 for multi6-data@psg.com; Tue, 18 Dec 2001 00:34:21 -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 16GFhc-0004aI-00 for multi6@ops.ietf.org; Tue, 18 Dec 2001 00:34:21 -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 JAA04546; Tue, 18 Dec 2001 09:34:19 +0100 Received: from dhcp222-13.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA62956 from ; Tue, 18 Dec 2001 09:34:18 +0100 Message-Id: <3C1EFF8A.5DE96FC8@hursley.ibm.com> Date: Tue, 18 Dec 2001 09:34:18 +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: multi6@ops.ietf.org Subject: Re: (multi6) requirements draft comments References: <2B81403386729140A3A899A8B39B046403D5A7@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 Michel Py wrote: ... > >> 3.1.6 > >> Multihoming solutions MUST provide re-homing transparency for > >> transport-layer sessions; i.e. exchange of data between devices on > >> the multihomed site and devices elsewhere on the Internet may > proceed > >> with no greater interruption than that associated with the > transient > >> packet loss during the re-homing event. > >> This appears to be requiring provider independence, since that is the > > >> only way to do this today. > > There might be other ways (TCP hacks/stack hacks), but the PI address > being the one that is configured on the hosts is the only proven one. Shame we don't have a PI solution that we actually know how to deploy and route at large scale. This requirement could lead to several other conclusions than PI: - need for an address-agile TCP - need for universal use of SCTP - need for 8+8 If it wasn't for the existence of these options as well as the illusory PI, I would recommend simply removing requirement 3.1.6 as unrealistic. Brian From owner-multi6@ops.ietf.org Tue Dec 18 08:32:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18649 for ; Tue, 18 Dec 2001 08:32:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16GKJx-0008LY-00 for multi6-data@psg.com; Tue, 18 Dec 2001 05:30:13 -0800 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.33 #1) id 16GKJw-0008LS-00 for multi6@ops.ietf.org; Tue, 18 Dec 2001 05:30:12 -0800 Received: (qmail 86166 invoked by uid 1000); 18 Dec 2001 13:30:11 -0000 Date: Tue, 18 Dec 2001 08:30:10 -0500 From: Joe Abley To: Brian E Carpenter Cc: Michel Py , multi6@ops.ietf.org Subject: Re: (multi6) requirements draft comments Message-ID: <20011218083010.E75641@buffoon.automagic.org> References: <2B81403386729140A3A899A8B39B046403D5A7@server2000.arneill-py.sacramento.ca.us> <3C1EFDA1.7C77FEA@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C1EFDA1.7C77FEA@hursley.ibm.com> User-Agent: Mutt/1.3.22.1i Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, Dec 18, 2001 at 09:26:09AM +0100, Brian E Carpenter wrote: > Michel Py wrote: > > > [...] > > > > This is vague indeed and I would not mind dropping 3.1.4 although it > > does not bother me. > > I think it needs to stay in, but the phrase "or application, NNTP, for example, " > should be deleted. That would leave the "example" sentence as > For example, customer C homed to ISP A may wish to shift traffic of a > certain class to ISP B as matter of policy. > which is necessary and sufficient IMHO. > > We could refine it further by saying "shift outgoing traffic" to make it > clear that this is not policy based routing. This sounds good to me. From owner-multi6@ops.ietf.org Tue Dec 18 10:08:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19641 for ; Tue, 18 Dec 2001 10:08:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16GLpt-0009dh-00 for multi6-data@psg.com; Tue, 18 Dec 2001 07:07:17 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16GLpt-0009db-00 for multi6@ops.ietf.org; Tue, 18 Dec 2001 07:07:17 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16GLpq-000E3R-00; Tue, 18 Dec 2001 07:07:14 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Brian E Carpenter Cc: multi6@ops.ietf.org Subject: Re: (multi6) requirements draft comments References: <2B81403386729140A3A899A8B39B046403D5A7@server2000.arneill-py.sacramento.ca.us> <3C1EFF8A.5DE96FC8@hursley.ibm.com> Message-Id: Date: Tue, 18 Dec 2001 07:07:14 -0800 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Shame we don't have a PI solution that we actually know how to deploy > and route at large scale. like democracy, it sucks, but less than any other way we actually have. > the illusory PI sadly, so far, it is the only non-illusory approach. it is actually deployed and being widely used, as opposed to, for example, using per-host ping as a routing protocol. no, we don't like it. but, though we have fears/worries, we don't have solid research/measurements about its actual scalability. and far worse, we have no alternatives which are on any platform other then powerpoint. randy From owner-multi6@ops.ietf.org Tue Dec 18 10:28:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19963 for ; Tue, 18 Dec 2001 10:28:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16GMAF-0009ye-00 for multi6-data@psg.com; Tue, 18 Dec 2001 07:28:19 -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 16GMAE-0009yX-00 for multi6@ops.ietf.org; Tue, 18 Dec 2001 07:28:18 -0800 Subject: RE: (multi6) requirements draft comments Date: Tue, 18 Dec 2001 07:28:18 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405DDE5@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: (multi6) requirements draft comments Thread-Index: AcGHyDPInaIVM0abQQ+vqDs6SsOPQgAD9TgQ content-class: urn:content-classes:message From: "Michel Py" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 To: "Joe Abley" , "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 KAA19963 > Dec 18, 2001 at 09:26:09AM +0100, Brian E Carpenter wrote: > Michel Py wrote: > > This is vague indeed and I would not mind dropping 3.1.4 although it > > does not bother me. > > I think it needs to stay in, but the phrase "or application, NNTP, for example, " > should be deleted. That would leave the "example" sentence as > For example, customer C homed to ISP A may wish to shift traffic of a > certain class to ISP B as matter of policy. > which is necessary and sufficient IMHO. > > We could refine it further by saying "shift outgoing traffic" to make it > clear that this is not policy based routing. > > Joe Abley wrote: > This sounds good to me. Sounds good to me too. Michel. From owner-multi6@ops.ietf.org Tue Dec 18 11:12:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20668 for ; Tue, 18 Dec 2001 11:12:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16GMqM-000AoD-00 for multi6-data@psg.com; Tue, 18 Dec 2001 08:11:50 -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 16GMqJ-000Ao3-00 for multi6@ops.ietf.org; Tue, 18 Dec 2001 08:11:47 -0800 Subject: RE: (multi6) requirements draft comments Date: Tue, 18 Dec 2001 08:11:47 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405DDE6@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: (multi6) requirements draft comments Thread-Index: AcGH2Emd01Yj/En2Qs6fy9f7UG+M7wAAGtGQ content-class: urn:content-classes:message From: "Michel Py" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 To: "Randy Bush" , "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 LAA20668 >> [Brian Carpenter] >> Shame we don't have a PI solution that we actually know how to deploy >> and route at large scale. > > [Randy Bush] > like democracy, it sucks, but less than any other way we actually have. > >> [Brian Carpenter] >> the illusory PI > > [Randy Bush] > sadly, so far, it is the only non-illusory approach. it is actually > deployed and being widely used, as opposed to, for example, using per-host > ping as a routing protocol. > no, we don't like it. but, though we have fears/worries, we don't have > solid research/measurements about its actual scalability. and far worse, > we have no alternatives which are on any platform other then powerpoint. >> [Brian Carpenter] >> This requirement could lead to several other conclusions than PI: I have to agree with Randy here. Granted, the PI approach has its own challenges, but it actually WORKS and is one of the building blocks of today's Internet. This discussion reminds me of the electric car: Gas cars pollute, let's replace them with electric. Two problems: electric cars do pollute too, because the electricity they use is produced by a coal plant, and because the disposal of half a ton of lead-acid batteries after they're gone is not friendly to the environment either. Besides, plugging it to recharge is a terrible hassle. I would love an electric car, and I will get one when I can get one that actually works. Today, the best I can think of is the hybrid; I might get one when my current car dies, but not before. The electric car failed because it was too many changes at the same time. Same thing applies to v6 multihoming. I personally don't have a problem with tossing the current model away to replace it with something else entirely new, as long as that something else is better than what we currently have and has reasonable expectations in terms of success. Given that the market will ultimately decide, it seems to me that the approach to v6 multihoming should be: 1. Provide v6 multihoming to EXISTING v4 multihoming sites/customers in a way that they would like, which probably requires PI. 2. By having these people moving to v6, it will then enable us to have a real environment to test new solutions that we design against. If there was a slam dunk solution for v6 multihoming, I would adopt it in a heartbeat. The reality check today is that nobody as invented it. This tells me that the road we need to pursue is an evolution of the current model as a headstart and continue to research other things as incremental changes. To conclude, let me repeat a few ideas that I have read in other documents that some of you might be familiar with: - The market does not like revolutions; the Internet has historically evolved with incremental changes. - What we decide in this workgroup is one thing, what the market does is quite another. - End-to-end connectivity is important. - An imperfect solution is better than no solution. Michel. From owner-multi6@ops.ietf.org Tue Dec 18 11:51:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21720 for ; Tue, 18 Dec 2001 11:51:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16GNQJ-000Ckv-00 for multi6-data@psg.com; Tue, 18 Dec 2001 08:48:59 -0800 Received: from mail6.microsoft.com ([131.107.3.126]) by psg.com with esmtp (Exim 3.33 #1) id 16GNQJ-000Ckn-00 for multi6@ops.ietf.org; Tue, 18 Dec 2001 08:48:59 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.195]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 18 Dec 2001 08:48:57 -0800 Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 18 Dec 2001 08:48:57 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 18 Dec 2001 08:48:55 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 18 Dec 2001 08:48:54 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Tue, 18 Dec 2001 08:47:20 -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="US-ASCII" Subject: RE: (multi6) requirements draft comments Date: Tue, 18 Dec 2001 08:47:20 -0800 Message-ID: Thread-Topic: (multi6) requirements draft comments Thread-Index: AcGH2Emd01Yj/En2Qs6fy9f7UG+M7wAAGtGQAAKGrGA= From: "Christian Huitema" To: "Michel Py" , "Randy Bush" , "Brian E Carpenter" Cc: X-OriginalArrivalTime: 18 Dec 2001 16:47:20.0639 (UTC) FILETIME=[A9099CF0:01C187E3] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA21720 > To conclude, let me repeat a few ideas that I have read in other documents > that some of you might be familiar with: > - The market does not like revolutions; the Internet has historically > evolved with incremental changes. > - What we decide in this workgroup is one thing, what the market does is > quite another. > - End-to-end connectivity is important. > - An imperfect solution is better than no solution. Nobody wants to throw away the existing solution, which is to inject a global route for a few multi-homed sites. However, this solution clearly has limits. Today, about 30% of the homes who have 1 PC also have a second one; is it absurd to think that tomorrow 30% of the homes who have DSL will also have a cable modem? What happens when 30% of home networks are multi-homed? I believe that we will see multiple solutions, and I would categorize these solutions in two large classes: the solutions that require the cooperation of the network service providers, and the solutions that don't. My contention is that a mass market solution should not require any action from the ISP. -- Christian Huitema From owner-multi6@ops.ietf.org Tue Dec 18 11:58:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21865 for ; Tue, 18 Dec 2001 11:58:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16GNWh-000CuI-00 for multi6-data@psg.com; Tue, 18 Dec 2001 08:55:35 -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 16GNWf-000CuB-00; Tue, 18 Dec 2001 08:55:34 -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 RAA08926; Tue, 18 Dec 2001 17:55:30 +0100 Received: from dhcp222-13.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA34102 from ; Tue, 18 Dec 2001 17:55:24 +0100 Message-Id: <3C1F74FD.21F1C988@hursley.ibm.com> Date: Tue, 18 Dec 2001 17:55:25 +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: Randy Bush , multi6@ops.ietf.org Subject: Re: (multi6) requirements draft comments References: <2B81403386729140A3A899A8B39B046405DDE6@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 We're miscommunicating a bit... see below Michel Py wrote: > > >> [Brian Carpenter] > >> Shame we don't have a PI solution that we actually know how to deploy > >> and route at large scale. > > > > [Randy Bush] > > like democracy, it sucks, but less than any other way we actually have. > > > >> [Brian Carpenter] > >> the illusory PI > > > > [Randy Bush] > > sadly, so far, it is the only non-illusory approach. it is actually > > deployed and being widely used, as opposed to, for example, using per-host > > ping as a routing protocol. Yes, it is what we do today in IPv4. But when I run the numbers for the future Internet, it becomes illusory for the reasons in draft-iab-bgparch-02.txt (which is supposed to be an RFC within 48 hours). > > no, we don't like it. but, though we have fears/worries, we don't have > > solid research/measurements about its actual scalability. and far worse, > > we have no alternatives which are on any platform other then powerpoint. Fully agree. All I am suggesting right now is that we don't *assume* PI is the answer for multi6. > > >> [Brian Carpenter] > >> This requirement could lead to several other conclusions than PI: > > I have to agree with Randy here. Granted, the PI approach has its own challenges, but it actually WORKS and is one of the building blocks of today's Internet. If I thought it would scale for tomorrow's Internet, we wouldn't be having this conversation. ... > Same thing applies to v6 multihoming. I personally don't have a problem with tossing the current model away to replace it with something else entirely new, as long as that something else is better than what we currently have and has reasonable expectations in terms of success. We agree. So don't build PI into the requirements of multi6. > > Given that the market will ultimately decide, it seems to me that the approach to v6 multihoming should be: > 1. Provide v6 multihoming to EXISTING v4 multihoming sites/customers in a way that they would like, which probably requires PI. > 2. By having these people moving to v6, it will then enable us to have a real environment to test new solutions that we design against. It may work out that way, but please don't build that into the requirements either. > > If there was a slam dunk solution for v6 multihoming, I would adopt it in a heartbeat. The reality check today is that nobody as invented it. This tells me that the road we need to pursue is an evolution of the current model as a headstart and continue to research other things as incremental changes. Please don't build that into the requirements either. Maybe somebody will invent the slam dunk when they see the agreed requirements. (Unlikely, but we mustn't exclude it by construction.) Brian From owner-multi6@ops.ietf.org Tue Dec 18 12:04:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21992 for ; Tue, 18 Dec 2001 12:04:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16GNfQ-000D89-00 for multi6-data@psg.com; Tue, 18 Dec 2001 09:04:36 -0800 Received: from sean.ebone.net ([195.158.227.211]) by psg.com with esmtp (Exim 3.33 #1) id 16GNfP-000D7w-00 for multi6@ops.ietf.org; Tue, 18 Dec 2001 09:04:35 -0800 Received: by sean.ebone.net (Postfix, from userid 1113) id 03B3284C; Tue, 18 Dec 2001 18:04:33 +0100 (CET) To: brian@hursley.ibm.com, randy@psg.com Subject: Re: (multi6) requirements draft comments Cc: multi6@ops.ietf.org Message-Id: <20011218170433.03B3284C@sean.ebone.net> Date: Tue, 18 Dec 2001 18:04:33 +0100 (CET) From: smd@ebone.net (Sean Doran) Sender: owner-multi6@ops.ietf.org Precedence: bulk Randy Bush writes: | > Shame we don't have a PI solution that we actually know how to deploy | > and route at large scale. | | like democracy, it sucks, but less than any other way we actually have. Well, my answer would be: we DO have a solution that we actually know how to deploy and route at large scale, BUT we do not know how to keep the routing dynamic in the presence of aggregation breakdown, EXCEPT for one technique: renumbering when connectivity changes. That is, in the presence of topology-change-driven renumbering, the current routing mechanisms are "good enough". Since we do not have such renumbering in IPv4 or in IPv6 yet, we have the PTOMAINE working-group. So, to some extent, Brian is right: PI implies the choice of non-optimal abstraction/aggregation boundaries, as opposed to PA, which generally are aligned with the connectivity graph. More particularly, PI addresses explicitly do not follow the connectivity graph, and do not fit into a new abstraction boundary as the PI-addressed things change (network) location. PI and PA are absolutely _awful_ terms that should be uninvented in favour of something that admits the truth that the optimal choice of numbers is driven by MATH and not by economics, and would clear up confusion among the various competing aggregation root and number-assignment proposals. Unfortunately, I am in one of those moods where all my creative acronyms that would replace "PI" are impolite. :-) [cf. my first paragraph] Sean. From owner-multi6@ops.ietf.org Tue Dec 18 12:16:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22204 for ; Tue, 18 Dec 2001 12:16:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16GNqD-000DRE-00 for multi6-data@psg.com; Tue, 18 Dec 2001 09:15:45 -0800 Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by psg.com with esmtp (Exim 3.33 #1) id 16GNqB-000DQd-00; Tue, 18 Dec 2001 09:15:44 -0800 Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id fBIHFQ612556; Tue, 18 Dec 2001 09:15:38 -0800 (PST) Received: from chuegenw2k (chuegen@chuegen-iosvpn-5.cisco.com [171.70.153.182]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with SMTP id JAA14717; Tue, 18 Dec 2001 09:15:23 -0800 (PST) From: "Craig A. Huegen" To: "Christian Huitema" , "Michel Py" , "Randy Bush" , "Brian E Carpenter" Cc: Subject: RE: (multi6) requirements draft comments Date: Tue, 18 Dec 2001 11:15:18 -0600 Message-ID: <011d01c187e7$91036b00$b69946ab@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Christian Huitema wrote: > Nobody wants to throw away the existing solution, which is to inject a > global route for a few multi-homed sites. However, this solution clearly > has limits. Today, about 30% of the homes who have 1 PC also have a > second one; is it absurd to think that tomorrow 30% of the homes who > have DSL will also have a cable modem? What happens when 30% of home > networks are multi-homed? While I agree with your sentiment, I believe there are multiple classes that must be considered. I don't believe that a user should be able to inject global prefixes from a cable modem and a DSL line at home; however, I do believe there's room for global prefixes to be injected by large, multi-national enterprises as end-users. I ask for caution within this community not to condemn a solution that may be right for the very large end-users because of a fear someone might want to apply it to home networks -- they're vastly different beasts. > I believe that we will see multiple solutions, and I would categorize > these solutions in two large classes: the solutions that require the > cooperation of the network service providers, and the solutions that > don't. My contention is that a mass market solution should not require > any action from the ISP. I would probably organize them a bit differently, based upon the characteristics of the multi-homed downstream/end-user networks. /cah From owner-multi6@ops.ietf.org Tue Dec 18 12:27:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22418 for ; Tue, 18 Dec 2001 12:27:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16GO1T-000DhX-00 for multi6-data@psg.com; Tue, 18 Dec 2001 09:27: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 16GO1T-000DhR-00 for multi6@ops.ietf.org; Tue, 18 Dec 2001 09:27:23 -0800 Subject: RE: (multi6) requirements draft comments Date: Tue, 18 Dec 2001 09:27:23 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405DDE8@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: (multi6) requirements draft comments Thread-Index: AcGH59zw9QyXcuH2RiGCTOg4kzlbsgAAKbGQ content-class: urn:content-classes:message From: "Michel Py" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 To: "Craig A. Huegen" , "Christian Huitema" 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 MAA22418 >> Christian Huitema wrote: >> I believe that we will see multiple solutions, and I would >> categorize these solutions in two large classes: the solutions >> that require the cooperation of the network service providers, >> and the solutions that don't. My contention is that a mass market >> solution should not require any action from the ISP. >> Craig A. Huegen wrote: >> While I agree with your sentiment, I believe there are multiple >> classes that must be considered. I don't believe that a user >> should be able to inject global prefixes from a cable modem and >> a DSL line at home; however, I do believe there's room for global >> prefixes to be injected by large, multi-national enterprises as >> end-users. I ask for caution within this community not to condemn >> a solution that may be right for the very large end-users because >> of a fear someone might want to apply it to home networks -- >> they're vastly different beasts. I fully agree with Christian and Craig here. I have proposed that idea of different classes a while ago on the mailing list (if you look into the archive, the title was "a new spin on multihoming: multihoming classes). It did not seem to trigger much interest at the time. Michel. From owner-multi6@ops.ietf.org Tue Dec 18 12:41:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22686 for ; Tue, 18 Dec 2001 12:41:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16GOF0-000Dzr-00 for multi6-data@psg.com; Tue, 18 Dec 2001 09:41:22 -0800 Received: from sean.ebone.net ([195.158.227.211]) by psg.com with esmtp (Exim 3.33 #1) id 16GOEz-000Dzj-00 for multi6@ops.ietf.org; Tue, 18 Dec 2001 09:41:21 -0800 Received: by sean.ebone.net (Postfix, from userid 1113) id 5F27984C; Tue, 18 Dec 2001 18:41:20 +0100 (CET) To: chuegen@cisco.com, huitema@windows.microsoft.com, michel@arneill-py.sacramento.ca.us Subject: RE: (multi6) requirements draft comments Cc: multi6@ops.ietf.org Message-Id: <20011218174120.5F27984C@sean.ebone.net> Date: Tue, 18 Dec 2001 18:41:20 +0100 (CET) From: smd@ebone.net (Sean Doran) Sender: owner-multi6@ops.ietf.org Precedence: bulk | I fully agree with Christian and Craig here. I have proposed that idea = | of different classes a while ago on the mailing list (if you look into = | the archive, the title was "a new spin on multihoming: multihoming = | classes). It did not seem to trigger much interest at the time. Unfortunately, IETF working groups are not captive audiences, and the volume of drafts means that anyone who participates in several WGs will have a hard time being motivated to keep up with a large fraction of them. While Thomas and I are obliged to try to focus everyone on the two drafts in the multi6 charter, I don't think many people would mind some small degree of "hey, go look at my draft-xyz-..., which is relevant", when it is indeed relevant to the discussions at hand. Sean. From owner-multi6@ops.ietf.org Tue Dec 18 14:41:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24965 for ; Tue, 18 Dec 2001 14:41:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16GQ6K-000GW7-00 for multi6-data@psg.com; Tue, 18 Dec 2001 11:40:32 -0800 Received: from sean.ebone.net ([195.158.227.211]) by psg.com with esmtp (Exim 3.33 #1) id 16GQ6J-000GVv-00 for multi6@ops.ietf.org; Tue, 18 Dec 2001 11:40:31 -0800 Received: by sean.ebone.net (Postfix, from userid 1113) id 3CFBE84D; Tue, 18 Dec 2001 20:40:30 +0100 (CET) To: alh-ietf@tndh.net, brian@hursley.ibm.com, randy@psg.com, smd@ebone.net Subject: RE: (multi6) requirements draft comments Cc: multi6@ops.ietf.org Message-Id: <20011218194030.3CFBE84D@sean.ebone.net> Date: Tue, 18 Dec 2001 20:40:30 +0100 (CET) From: smd@ebone.net (Sean Doran) Sender: owner-multi6@ops.ietf.org Precedence: bulk | Deploying the router and host mechansims which would implement topology | based renumbering is hard enough, but replacing all the applications | with ones that ignore those changes is a fantasy which would have to | happen before the infrastructure based renumbering could even begin. 8+8-type proposals rely upon the host and/or router to deliberately hide the upper octets ("routing goop") from the applications, which see all-zeros or the like. Some people (I am wary of identifying them without permission) had begun to enumerate the various places one would have to change host implementations, such as in in-stack checksumming code, but I have not heard of this being finished. | Fold in the fact that even if you got those to things done, the topology | shift renumbering would create a DNS update spike that would take out | all name services, and one wonders why the approach is still getting any | attention. The hosts could remember /<8-or-10-or-whatever-bytes-of-identity> in their DNS caches; there are techniques learned from NAT that make handling this quite simple. For instance, if you couple an IPv4 NAT or a routing-goop-rewriter with what appears to be a caching DNS server, you can have a different view of the "outside"'s DNS from that known on the "inside". This is not "classical 8+8", which indeed would require hosts to learn that routing-goop-value-x has just become routing-goop-value-y, in order to continue talking with the parties who changed RG values, or in waiting for them to learn that themselves from the DNS, or from a mechanism along the lines discussed in the review of Ohta-san's draft. There are connectivity-debugging implications associated with all of these approaches, however, as many people have pointed out. The question is, how should such implications be addressed (pardon the pun) in the requirements draft? Sean. From owner-multi6@ops.ietf.org Tue Dec 18 15:05:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25654 for ; Tue, 18 Dec 2001 15:05:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16GQTM-000Gz3-00 for multi6-data@psg.com; Tue, 18 Dec 2001 12:04:20 -0800 Received: from zeus.anet-chi.com ([207.7.4.6]) by psg.com with esmtp (Exim 3.33 #1) id 16GQTL-000Gyx-00; Tue, 18 Dec 2001 12:04:19 -0800 Received: from IPv16 (as1b-67.chi.il.dial.anet.com [198.92.157.67]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id fBIK30AC014650; Tue, 18 Dec 2001 14:03:01 -0600 (CST) Message-ID: <048e01c18800$fb40f3c0$1000a8c0@Unir.com> From: "Jim Fleming" To: , , , Cc: References: <20011218194030.3CFBE84D@sean.ebone.net> Subject: Re: (multi6) requirements draft comments Date: Tue, 18 Dec 2001 14:17:08 -0600 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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Since 2002 is almost here, you might want to consider running IPv4 in 2002 Mode. 2002::0000.... This may help... http://www.dot-biz.com/IPv4/Tutorial/ http://www.RepliGate.net The Netfilter Project: Packet Mangling for Linux 2.4 http://netfilter.samba.org Jim Fleming http://www.IPv8.info IPv16....One Better !! ----- Original Message ----- From: "Sean Doran" To: ; ; ; Cc: Sent: Tuesday, December 18, 2001 1:40 PM Subject: RE: (multi6) requirements draft comments > | Deploying the router and host mechansims which would implement topology > | based renumbering is hard enough, but replacing all the applications > | with ones that ignore those changes is a fantasy which would have to > | happen before the infrastructure based renumbering could even begin. > > 8+8-type proposals rely upon the host and/or router to deliberately > hide the upper octets ("routing goop") from the applications, > which see all-zeros or the like. > > Some people (I am wary of identifying them without permission) had > begun to enumerate the various places one would have to change > host implementations, such as in in-stack checksumming code, > but I have not heard of this being finished. > > | Fold in the fact that even if you got those to things done, the topology > | shift renumbering would create a DNS update spike that would take out > | all name services, and one wonders why the approach is still getting any > | attention. > > The hosts could remember /<8-or-10-or-whatever-bytes-of-identity> > in their DNS caches; there are techniques learned from NAT that make > handling this quite simple. > > For instance, if you couple an IPv4 NAT or a routing-goop-rewriter > with what appears to be a caching DNS server, you can have a different > view of the "outside"'s DNS from that known on the "inside". > > This is not "classical 8+8", which indeed would require hosts > to learn that routing-goop-value-x has just become routing-goop-value-y, > in order to continue talking with the parties who changed RG values, > or in waiting for them to learn that themselves from the DNS, > or from a mechanism along the lines discussed in the review > of Ohta-san's draft. > > There are connectivity-debugging implications associated > with all of these approaches, however, as many people have > pointed out. The question is, how should such implications > be addressed (pardon the pun) in the requirements draft? > > Sean. > > From owner-multi6@ops.ietf.org Tue Dec 18 20:24:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02849 for ; Tue, 18 Dec 2001 20:24:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16GVRO-000MiO-00 for multi6-data@psg.com; Tue, 18 Dec 2001 17:22:38 -0800 Received: from nox.sandelman.ottawa.on.ca ([192.139.46.6] helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 3.33 #1) id 16GVRN-000MiI-00 for multi6@ops.ietf.org; Tue, 18 Dec 2001 17:22:37 -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 fBJ1MTD06248 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Tue, 18 Dec 2001 20:22:36 -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 fBJ1L8O03945 for ; Tue, 18 Dec 2001 20:21:13 -0500 (EST) Message-Id: <200112190121.fBJ1L8O03945@marajade.sandelman.ottawa.on.ca> To: multi6@ops.ietf.org Subject: Re: (multi6) requirements draft comments In-reply-to: Your message of "Tue, 18 Dec 2001 11:15:18 CST." <011d01c187e7$91036b00$b69946ab@cisco.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 18 Dec 2001 20:21:08 -0500 From: Michael Richardson Sender: owner-multi6@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Craig" == Craig A Huegen writes: Craig> While I agree with your sentiment, I believe there are multiple Craig> classes that must be considered. I don't believe that a user Craig> should be able to inject global prefixes from a cable modem and a Craig> DSL line at home; however, I do believe there's room for global Craig> prefixes to be injected by large, multi-national enterprises as Craig> end-users. I ask for caution within this community not to condemn Craig> a solution that may be right for the very large end-users because Craig> of a fear someone might want to apply it to home networks -- Craig> they're vastly different beasts. I believe that there are three solution spaces: 1) large multi-national entreprise solutions. (if you have geographically relevant addressing, either via geo-PI, or via national governments doing all assignments. Perhaps not a reality in the "free markets", but possibly true for other less free areas, but also places like Antartica, the Moon, Mars...) This is more or less the BGP solution space. 2) network layer solutions. mobile-IP like systems. Some people believe that this requires some kind of global PKI on the reverse name space. (note: PKI = PK infrastructure, which maybe PK+DNSSEC. It may not imply x509/pkix) opportunistic-encryption-like-tunnel systems. Given the above global PKI, you can assign PI addresses to everyone which are *not* routed. You can then advertise how to get to these places by putting stuff into DNS reverse map. (see draft-richardson-ipsec-opportunistic-03.txt) This is no different than the mobile-IP system, it just never tries to optomize anything. HIP-like systems- a variation of the above where IP addresess become meaningless, and hashes of public keys terminate connections. 3) transport layer solutions. Just use SCTP for everything with PA addressing. None of these solutions are even exclusive. I can see all three systems occuring at the same time. ] 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"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPB/rgoqHRg3pndX9AQHnWAP7BpRW5NHLj3HXvfP8DrN27MPXledVYily GUwPrvp0nv7m+SAdYWkx/zgnvsTTbJk2nJo2Eev0a87zlLiFVSnk1SUjVJNh2aJD DAtqde3MCl01cutaEKvZnTMRq63lf7+vihNfu4/86LUN0R7ZjsoSmXOmEFELyZg0 wzOc5c7XNCw= =9vd7 -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Dec 18 21:37:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04544 for ; Tue, 18 Dec 2001 21:37:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16GWbO-000NyN-00 for multi6-data@psg.com; Tue, 18 Dec 2001 18:37:02 -0800 Received: from evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net ([4.60.69.141] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.33 #1) id 16GWbN-000NyG-00 for multi6@ops.ietf.org; Tue, 18 Dec 2001 18:37:01 -0800 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Tue, 18 Dec 2001 11:01:47 -0800 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 7225007A405E478CBF4C61B40984D6B1 for plus 3 more; Tue, 18 Dec 2001 11:01:47 -0800 From: "Tony Hain" To: "Sean Doran" , , Cc: Subject: RE: (multi6) requirements draft comments Date: Tue, 18 Dec 2001 10:57:53 -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) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <20011218170433.03B3284C@sean.ebone.net> X-SLUIDL: 778E2D5B-10904C3E-B4CFA603-51E753D2 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Sean Doran wrote: > That is, in the presence of topology-change-driven renumbering, > the current routing mechanisms are "good enough". Since we > do not have such renumbering in IPv4 or in IPv6 yet, we have > the PTOMAINE working-group. Deploying the router and host mechansims which would implement topology based renumbering is hard enough, but replacing all the applications with ones that ignore those changes is a fantasy which would have to happen before the infrastructure based renumbering could even begin. Fold in the fact that even if you got those to things done, the topology shift renumbering would create a DNS update spike that would take out all name services, and one wonders why the approach is still getting any attention. Tony From owner-multi6@ops.ietf.org Tue Dec 18 22:41:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06230 for ; Tue, 18 Dec 2001 22:41:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16GXaX-000Owf-00 for multi6-data@psg.com; Tue, 18 Dec 2001 19:40:13 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.33 #1) id 16GXaW-000OwV-00 for multi6@ops.ietf.org; Tue, 18 Dec 2001 19:40:12 -0800 Subject: RE: (multi6) requirements draft comments Date: Tue, 18 Dec 2001 19:40:10 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405DDF3@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" content-class: urn:content-classes:message Thread-Topic: (multi6) requirements draft comments X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Index: AcGILZOnAskNsF3bRB6MlGKDhcuo4wAEFUhQ 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 WAA06230 I agree with Michael on the three spaces here, and I will add that, since the current focus of this working group is "site multihoming", we should acknowledge mobile as part of the multihoming problem and decide if it is within the scope of the WG or not. >> Michael Richardson wrote: >> I believe that there are three solution spaces: >> 1) large multi-national entreprise solutions. >> (if you have geographically relevant addressing, either via >> geo-PI, or via national governments doing all assignments. Perhaps >> not a reality in the "free markets", but possibly true for other >> less free areas, but also places like Antartica, the Moon, Mars...) >> >> This is more or less the BGP solution space. >> 2) network layer solutions. >> mobile-IP like systems. >> Some people believe that this requires some kind of global PKI >> on the reverse name space. (note: PKI = PK infrastructure, which >> maybe PK+DNSSEC. It may not imply x509/pkix) >> opportunistic-encryption-like-tunnel systems. >> Given the above global PKI, you can assign PI addresses to everyone >> which are *not* routed. You can then advertise how to get to these >> places by putting stuff into DNS reverse map. >> (see draft-richardson-ipsec-opportunistic-03.txt) >> This is no different than the mobile-IP system, it just never tries >> to optomize anything. >> HIP-like systems- a variation of the above where IP addresess >> become meaningless, and hashes of public keys terminate >> connections. >> 3) transport layer solutions. >> Just use SCTP for everything with PA addressing. >> None of these solutions are even exclusive. I can see all three systems >> occuring at the same time. From owner-multi6@ops.ietf.org Tue Dec 18 23:03:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06473 for ; Tue, 18 Dec 2001 23:03:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16GXwD-000PHq-00 for multi6-data@psg.com; Tue, 18 Dec 2001 20:02:37 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.33 #1) id 16GXwC-000PHk-00 for multi6@ops.ietf.org; Tue, 18 Dec 2001 20:02:36 -0800 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id XAA03893; Tue, 18 Dec 2001 23:02:34 -0500 Date: Tue, 18 Dec 2001 23:02:34 -0500 From: "J. Noel Chiappa" Message-Id: <200112190402.XAA03893@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: RE: (multi6) requirements draft comments Cc: jnc@ginger.lcs.mit.edu Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: "Tony Hain" > replacing all the applications with ones that ignore those changes is a > fantasy .. even if you got those to things done, the topology shift > renumbering would create a DNS update spike that would take out all > name services I must confess I've only been listening to this exchange with half of one ear, so perhaps I've missed something, but I'm wondering what your proposed better mousetrap is (since you don't like this one). Sure, supporting multi-homing in the routing works for a few sites, but if (say) 30% of all homes are multi-homed (to produce a nice big user base), and want open connections to stay up when the "primary" link fails (the most technically aggressive case), then trying to do it in the routing just isn't going to fly, at least without a fairly radical routing-name allocation system (see below). Remember the "Key Multihoming Observation #0" from: http://ana-3.lcs.mit.edu/~jnc/tech/nsrg/multihoming_points.txt which is: "TANSTAAFL: There Ain't No Such Thing As A Free Lunch" Multihoming is something that is done to provide *benefits*. Those are not *free*. There is a *cost* for them ... In other words, don't expect to get the benefits of globally deployed multi- homing without paying some costs. So people who say "oh, we have multi-homing now, what's the problem" - that's total bilge. We don't have real multi-homing - we have a hack that works if only a few people use it (i.e. low systemic cost). To explain my aside about "fairly radical routing-name allocation", Kleinrock/Kamoun says that you can get scalable routing in *any* arbitrary graph (including ones with every house multihomed), so theoretically at least we might be able to get multi-homing support with the support costs buried in the routing overhead. (Actually, now that I think about it, I'd better go check that their results to apply to *any* random graph; more on this below.) However, I don't think we're going to get there with the current routing-name allocation system; we'd probably have to have some fairly radical system where there's *lots* of aggregation (i.e. lots of layers) - and the placing of the topological boundaries (i.e. routing-name assignment) is completely automated. To put this a little more concretely, if you read the K-K math, their results hold for their optimal aggregate size which is, IIRC, "e". That's right, 3 level-N entities per level-(N-1) object. So a network X nodes would need ln(X) levels of addressing; e.g. a 100M node Internet would need 19 layers of addressing. Now, it turns out you don't really have to go to that extreme, since their scheme produces ridiculously tiny routing tables; IIRC, they are e * ln(X). We don't really need 60 entry routing tables! Still, a address aggregation hierarchy which did work with large numbers of multihomed sites would probably do things like group me and my neighours who have CATV into one fairly low-level entity - and assign *both* the CATV and DSL links a single fairly-low-level routing-name - which probably wouldn't sit well with the relevant companies. Now that I think about it, though (this is the aside from above), it's perhaps the case that there are very pathological graphs in which the K-K results *don't* hold - and a graph in which there are basically two kinds of nodes, a very large group with only two neighbours, and a very small group with many thouands, might be one. This makes sense: it will be impossible to form those 3-element groups (remember them?) in such a graph. So, perhaps there is no routing solution, even with an aggressive, and fully automatic, routing-name allocation. So if you can't cram it into the routing that way, you're pretty much back to the "you have two routing-names (i.e. addresses)" approach, with all that implies. But remember, TANSTAAFL. Somebody, somewhere, has to pay (and I don't mean $) to roll out this wonderful benefit. I will leave you wth another quote from that document: JNC Corollary to the JTW Principle: - It is best if one can allocate the costs so that the entities which benefit from the multihoming are the ones to bear the cost. I was going to say more about multiple routing-names, but I seem to have run out of brain cells. Anyway, this is long enough already. Noel From owner-multi6@ops.ietf.org Tue Dec 18 23:12:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06633 for ; Tue, 18 Dec 2001 23:12:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16GY58-000PSA-00 for multi6-data@psg.com; Tue, 18 Dec 2001 20:11:50 -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 16GY57-000PS3-00 for multi6@ops.ietf.org; Tue, 18 Dec 2001 20:11:49 -0800 Subject: RE: (multi6) requirements draft comments Date: Tue, 18 Dec 2001 20:11:50 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405DDF4@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: (multi6) requirements draft comments content-class: urn:content-classes:message Thread-Index: AcGH5OxUut8GozGiQYiTSHOUIq1HZgAWfihg X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 From: "Michel Py" To: "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 XAA06633 Brian, >> Fully agree. All I am suggesting right now is that we don't >> *assume* PI is the answer for multi6. Enhanced PI is the SHORT-TERM answer to multi6. >> If I thought it would scale for tomorrow's Internet, we >> wouldn't be having this conversation. It does not scale, and we know it (although there are ways to scrounge 10 or more years out of it). And, a bad solution is better than no solution. >> We agree. So don't build PI into the requirements of multi6. I am not advocating to build PI into the requirements of multi6. >>>> This tells me that the road we need to pursue is an >>>> evolution of the current model as a headstart and continue >>>> to research other things as incremental changes >> Please don't build that into the requirements either. Maybe >> somebody will invent the slam dunk when they see the agreed >> requirements. (Unlikely, but we mustn't exclude it by >> construction.) IMHO, this is not relevant. If somebody invents the improbable universal solution that everyone here has failed to grasp, we will all agree to toss the requirements overboard. What I am advocating for is being realistic: 1. As Randy said, we do have a collective responsability to bring the IPv6 community more or less what exists today for IPv4 and try to clean it as we go. *** hint *** http://search.ietf.org/internet-drafts/draft-py-multi6-mhtp-01.txt 2. This is not enough. No single solution actually answers the big-picture problem and there are three main areas, or classes, or spaces or whatever that needs to be addressed: big honkin' setup, home/soho, and mobile, probably with some overlap. 3. The current requirements draft is blocking solutions from being developped and, as Christian said, it's time to put it to bed. Michel. From owner-multi6@ops.ietf.org Wed Dec 19 08:04:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27648 for ; Wed, 19 Dec 2001 08:04:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16GgLC-0006rG-00 for multi6-data@psg.com; Wed, 19 Dec 2001 05:00:58 -0800 Received: from zeus.anet-chi.com ([207.7.4.6]) by psg.com with esmtp (Exim 3.33 #1) id 16GgLB-0006rA-00 for multi6@ops.ietf.org; Wed, 19 Dec 2001 05:00:57 -0800 Received: from IPv16 (as1b-67.chi.il.dial.anet.com [198.92.157.67]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id fBJD0nxj011311; Wed, 19 Dec 2001 07:00:50 -0600 (CST) Message-ID: <005c01c1888f$1c5de160$1000a8c0@Unir.com> From: "Jim Fleming" To: "J. Noel Chiappa" , Cc: References: <200112190402.XAA03893@ginger.lcs.mit.edu> Subject: Re: (multi6) requirements draft comments Date: Wed, 19 Dec 2001 07:14:35 -0600 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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "J. Noel Chiappa" > > However, I don't think we're going to get there with the current routing-name > allocation system; we'd probably have to have some fairly radical system > where there's *lots* of aggregation (i.e. lots of layers) - and the placing > of the topological boundaries (i.e. routing-name assignment) is completely > automated. > The "toy" legacy IPv4 Internet does not do routing, it does forwarding. As for "lots of layers"..... This may help... http://www.dot-biz.com/IPv4/Tutorial/ http://www.RepliGate.net The Netfilter Project: Packet Mangling for Linux 2.4 http://netfilter.samba.org Jim Fleming http://www.IPv8.info IPv16....One Better !! From owner-multi6@ops.ietf.org Wed Dec 19 11:31:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01109 for ; Wed, 19 Dec 2001 11:31:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16GjaI-0009sl-00 for multi6-data@psg.com; Wed, 19 Dec 2001 08:28:46 -0800 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by psg.com with esmtp (Exim 3.33 #1) id 16GjaI-0009sf-00 for multi6@ops.ietf.org; Wed, 19 Dec 2001 08:28:46 -0800 Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBJGSjG00867; Wed, 19 Dec 2001 08:28:45 -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 fBJGSjB22557; Wed, 19 Dec 2001 08:28:45 -0800 (PST) Message-Id: <5.1.0.14.2.20011219082413.00ae04e8@lint.cisco.com> X-Sender: elear@lint.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 19 Dec 2001 08:28:41 -0800 To: "Jim Fleming" From: Eliot Lear Subject: Re: (multi6) requirements draft comments Cc: multi6@ops.ietf.org In-Reply-To: <005c01c1888f$1c5de160$1000a8c0@Unir.com> References: <200112190402.XAA03893@ginger.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-multi6@ops.ietf.org Precedence: bulk In a long line of silly comments, this is silliest. Telling one of the people who invented the concept of routing (and patented the multiprotocol router) that IPv4 Internet doesn't do routing just shows willful ignorance. Please go away. Perhaps the chair can help in this matter. Plonk. At 07:14 AM 12/19/2001 -0600, Jim Fleming wrote: >----- Original Message ----- >From: "J. Noel Chiappa" > > > > However, I don't think we're going to get there with the current > routing-name > > allocation system; we'd probably have to have some fairly radical system > > where there's *lots* of aggregation (i.e. lots of layers) - and the placing > > of the topological boundaries (i.e. routing-name assignment) is completely > > automated. > > > >The "toy" legacy IPv4 Internet does not do routing, it does forwarding. > >As for "lots of layers"..... > >This may help... >http://www.dot-biz.com/IPv4/Tutorial/ >http://www.RepliGate.net > >The Netfilter Project: Packet Mangling for Linux 2.4 >http://netfilter.samba.org > >Jim Fleming >http://www.IPv8.info >IPv16....One Better !! From owner-multi6@ops.ietf.org Wed Dec 19 11:46:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01382 for ; Wed, 19 Dec 2001 11:46:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Gjqp-000AAe-00 for multi6-data@psg.com; Wed, 19 Dec 2001 08:45:51 -0800 Received: from sean.ebone.net ([195.158.227.211]) by psg.com with esmtp (Exim 3.33 #1) id 16Gjqp-000AAY-00 for multi6@ops.ietf.org; Wed, 19 Dec 2001 08:45:51 -0800 Received: by sean.ebone.net (Postfix, from userid 1113) id 07EB784C; Wed, 19 Dec 2001 17:45:49 +0100 (CET) To: jfleming@anet.com, lear@cisco.com Subject: administrivia: netiquette Cc: multi6@ops.ietf.org Message-Id: <20011219164549.07EB784C@sean.ebone.net> Date: Wed, 19 Dec 2001 17:45:49 +0100 (CET) From: smd@ebone.net (Sean Doran) Sender: owner-multi6@ops.ietf.org Precedence: bulk All - At least one of the two co-chairs (me) believes that restraining oneself from calling a posting of any nature by any epithet which is self-evident, is within the ability of all subscribers to the list, and is a good idea to reduce the amount of traffic. Amplifying what some consider "problem postings" by starting metadiscussions about them are counterproductive. Likewise, we do not need to know who goes into your killfiles, procmails, or what-have-you. Constructive postings are always welcome, and indeed, any posting that focuses on the two drafts in our charter are appropriate. Administrative complaints should be directed to the co-chairs directly, rather than aired out on the list. Name-calling should be directed to individuals, not to the list. Please, if you have a problem with this policy, take it up with me and/or my co-chair at the email addresses on our charter page: http://www.ietf.org/html.charters/multi6-charter.html Thanks, Sean. From owner-multi6@ops.ietf.org Wed Dec 19 11:46:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01395 for ; Wed, 19 Dec 2001 11:46:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16GjrV-000ABg-00 for multi6-data@psg.com; Wed, 19 Dec 2001 08:46:33 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.33 #1) id 16GjrV-000ABa-00 for multi6@ops.ietf.org; Wed, 19 Dec 2001 08:46:33 -0800 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id LAA05312; Wed, 19 Dec 2001 11:46:30 -0500 Date: Wed, 19 Dec 2001 11:46:30 -0500 From: "J. Noel Chiappa" Message-Id: <200112191646.LAA05312@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: (multi6) requirements draft comments Cc: jnc@ginger.lcs.mit.edu Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Eliot Lear > one of the people who invented the concept of routing (and patented the > multiprotocol router) Alas, I wish I had! I did co-invent the concept of the multi-protocol router (after some investigation, it appears that Bill Yeager at Stanford was doing some multi-protocol stuff at about the same time as I was, at MIT), but we never had the wit to patent it! Too bad, we'd have been bazillionaires! Also, I didn't invent the concept of routing (in the sense of internetwork forwarding) - that was some collection of Cerf, Kahn and a couple of other people. Noel From owner-multi6@ops.ietf.org Wed Dec 19 11:47:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01411 for ; Wed, 19 Dec 2001 11:47:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16GjsD-000ACX-00 for multi6-data@psg.com; Wed, 19 Dec 2001 08:47:17 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16GjsC-000ACR-00 for multi6@ops.ietf.org; Wed, 19 Dec 2001 08:47:16 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16Gjs6-0004HV-00; Wed, 19 Dec 2001 08:47:10 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Eliot Lear Cc: multi6@ops.ietf.org Subject: Re: (multi6) requirements draft comments References: <200112190402.XAA03893@ginger.lcs.mit.edu> <5.1.0.14.2.20011219082413.00ae04e8@lint.cisco.com> Message-Id: Date: Wed, 19 Dec 2001 08:47:10 -0800 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > To: "Jim Fleming" please do not feed the trolls. they can not digest it, and only puke on the floor. randy From owner-multi6@ops.ietf.org Wed Dec 19 13:04:14 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02918 for ; Wed, 19 Dec 2001 13:04:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Gl3l-000BbM-00 for multi6-data@psg.com; Wed, 19 Dec 2001 10:03:17 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.33 #1) id 16Gl3j-000Bb9-00 for multi6@ops.ietf.org; Wed, 19 Dec 2001 10:03:15 -0800 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id NAA05520; Wed, 19 Dec 2001 13:03:12 -0500 Date: Wed, 19 Dec 2001 13:03:12 -0500 From: "J. Noel Chiappa" Message-Id: <200112191803.NAA05520@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: RE: (multi6) requirements draft comments Cc: jnc@ginger.lcs.mit.edu Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: "J. Noel Chiappa" Now that I've had some sleep, and my neurons are fresh, I have a few more things to say about this topic... > Kleinrock/Kamoun says that you can get scalable routing in *any* > arbitrary graph .. so theoretically at least we might be able to get > multi-homing support with the support costs buried in the routing > overhead. > ... > if you read the K-K math, their results hold for their optimal > aggregate size which is, IIRC, "e". That's right, 3 level-N entities > per level-(N-1) object. I checked, and it is indeed e. Of course, that's a real-number solution which doesn't apply to actual graphs, but they further go on to prove that for that case, there's a global optimum with at most two levels of 2, and the rest of 3. > Still, a address aggregation hierarchy which did work with large > numbers of multihomed sites would probably do things like group me and > my neighours who have CATV into one fairly low-level entity - and > assign *both* the CATV and DSL links a single fairly-low-level > routing-name ... > it's perhaps the case that there are very pathological graphs in which > the K-K results *don't* hold - and a graph in which there are basically > two kinds of nodes, a very large group with only two neighbours, and a > very small group with many thouands, might be one. This makes sense: it > will be impossible to form those 3-element groups (remember them?) in > such a graph. I thought about this some more, and checked the K-K paper, and I think their results do hold for all graphs, but I need to study it some more (which I don't really feel up to at the moment, frankly) to see if it still holds in cases such as the one I outlined, in which the degree of a few nodes nodes is very large, and of most nodes is very small. However, that's to some degree irrelevant, because by thinking about it from this point of view, it's become clear to me what one has to do (in terms of the node routing-name assignment) to get the most efficient (in overhead terms) possible results from doing multihoming support in the routing. It's easiest to explain all this if I give an example. I came to this as a kind of picture in my head, but it's not a picture I can easily put onto a plane surface, so I'll try to do it with precise "words" instead. Let's suppose that I'm in a place served by M different CATV providers (I know in most places in the real world it's a monopoly, but I want to make a point), C1 ... CM, and N DSL providers, D1 ... DN. Of all the houses H1...Hn in the area, some subset S0j are served by one DSL provider only, provider Dj, and some subset by CATV provider Ci only, Si0. Those guys are simple, we don't care about them. We need to think about the sets Sij, which are served by one CATV provider, Ci, and one DSL provider, Dj. (There are also other sets which have more than one CATV and/or more than one DSL, but let's leave them for the moment - the system will extend to them.) What you have to do is group (on the graph, which is how I came to this, but it's hard to draw) all those nodes in set Sij together, and put a topology naming boundary around them. I.e. assign that set a "network number", and give them all routing-names from that network number. So house Hk which is in set Sij will have routing-name "Sij".k (where "Sij" is the routing-name of that set). (Obviously, if M and/or N get large, the set S* of sets Sij as well as the sets of things with 3 or more connections can get pretty large [I forget whether it's an exponential in M+N, or a factorial - probably the latter, but it's not important], but let's gloss over that for now.) This is what you *have* to do to get as close as you reasonably can to the K-K ideal of efficient (in terms of minimizing table size) routing. Some of you may hear echoes of metro addressing in this, but there is a crucial difference. In metro-addressing, routing-names are assigned, and then the topology is constrained to meet certain properties. In this system, it's the other way around: if you sign up for a different set of providers, you have to get a new routing-name. Well, that's no surprise; your routing-name says where you are in the network, and if you change your location (into a different grouping), you need a new routing-name. What's more interesting is to think about what happens when there's a failure. This is *not* a situation that K-K talks about - they are simply analyzing the most efficient naming hiearchy for optimal (in terms of minimum table size) routing. If anyone cares about this, I'll talk about that in a separate message, this one is already too long. Noel From owner-multi6@ops.ietf.org Wed Dec 19 16:33:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07883 for ; Wed, 19 Dec 2001 16:33:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16GoIF-000FjX-00 for multi6-data@psg.com; Wed, 19 Dec 2001 13:30:27 -0800 Received: from evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net ([4.60.69.141] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.33 #1) id 16GoID-000FjL-00 for multi6@ops.ietf.org; Wed, 19 Dec 2001 13:30:25 -0800 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Wed, 19 Dec 2001 12:08:17 -0800 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 2B2F7129552C420A9294F3CC7F7080CC for plus 1 more; Wed, 19 Dec 2001 12:08:16 -0800 From: "Tony Hain" To: "J. Noel Chiappa" , Subject: RE: (multi6) requirements draft comments Date: Wed, 19 Dec 2001 12:04: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) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <200112191803.NAA05520@ginger.lcs.mit.edu> X-SLUIDL: 92855645-009649B1-A5A1BE85-8A8A6075 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit J. Noel Chiappa wrote: > Some of you may hear echoes of metro addressing in this, but > there is a > crucial difference. In metro-addressing, routing-names are > assigned, and then > the topology is constrained to meet certain properties. In > this system, it's > the other way around: if you sign up for a different set of > providers, you > have to get a new routing-name. So there is a prefix for every combination of possible providers a customer can subscribe from, but how would that scale globally? The fact that I can't get service from Telstra doesn't mean that someone in another area of attbi / verizon coverage would not be able to. How would the providers know where the overlaps are to route correctly, unless their competitors exposed plans to offer service in an area before it happened? How would routing work if those overlap areas were discontiguous? This approach moves the scaling problem from the technical space to the administrative space, where the complexity would create prohibitive costs. Tony From owner-multi6@ops.ietf.org Wed Dec 19 16:33:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07896 for ; Wed, 19 Dec 2001 16:33:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16GoIF-000FjZ-00 for multi6-data@psg.com; Wed, 19 Dec 2001 13:30:27 -0800 Received: from evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net ([4.60.69.141] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.33 #1) id 16GoID-000FjK-00 for multi6@ops.ietf.org; Wed, 19 Dec 2001 13:30:25 -0800 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Wed, 19 Dec 2001 11:37:08 -0800 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id A6AF88ED27674677B6D62849C5BE6766 for plus 1 more; Wed, 19 Dec 2001 11:37:08 -0800 From: "Tony Hain" To: "J. Noel Chiappa" , Subject: RE: (multi6) requirements draft comments Date: Wed, 19 Dec 2001 11:33:11 -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) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <200112190402.XAA03893@ginger.lcs.mit.edu> X-SLUIDL: 2FA0351E-CC244878-A790332E-331D1573 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit J. Noel Chiappa wrote: > I must confess I've only been listening to this exchange with > half of one > ear, so perhaps I've missed something, but I'm wondering what > your proposed > better mousetrap is (since you don't like this one). The primary problem is assuming there exists a one-size-fits-all solution to the multi-facetted routing problem. We are currently restricted to a one-size-fits-all routing protocol, so I believe we need to allow another variable to change if we expect to meet the needs of different sites. > Sure, supporting multi-homing in the routing works for a few > sites, but if > (say) 30% of all homes are multi-homed (to produce a nice big > user base), and > want open connections to stay up when the "primary" link > fails (the most > technically aggressive case), then trying to do it in the > routing just isn't > going to fly, at least without a fairly radical routing-name > allocation > system Actually the problem of maintaining connections is the easier one technically, but the solution doesn't sit well with some incumbent operators. The problem is handling the large sites that expect to be able to engineer traffic flows, where the definition of that kind of site needs to be crisp enough for the registries to distinguish it from a home or a service provider. As far as radical routing-name allocation system's go, several people on this list consider my proposal draft-hain-ipv6-pi-addr-01.txt & draft-hain-ipv6-pi-addr-use-01.txt in that catagory, but I just consider it to be an overlay that complements the current scheme. > Still, a address aggregation hierarchy which did work with > large numbers of > multihomed sites would probably do things like group me and > my neighours who > have CATV into one fairly low-level entity - and assign > *both* the CATV and > DSL links a single fairly-low-level routing-name - which > probably wouldn't > sit well with the relevant companies. This is fundamentally what I am suggesting, and it is being received about as well as you have expected. To a first order, the bit pattern really doesn't matter, it is the architectural concept that service providers need to share customer access that is the stumbling block. Since this is diametrically opposed to their business model the number of possible technical solutions approaches 0 very quickly. > So, perhaps there is no routing solution, even with an > aggressive, and fully > automatic, routing-name allocation. At least no single one. > So if you can't cram it into the routing that way, you're > pretty much back to > the "you have two routing-names (i.e. addresses)" approach, > with all that > implies. I agree, but it really is a function of site goals as to which of the N routing-names it wants to use for any particular application. It is certainly reasonable for things which need to survive provider failures to be in an independent address space, but if that is not a site requirement, using N instances of PA space scales better in the routing complex because it moves the scaling issue to the edge. Tony From owner-multi6@ops.ietf.org Wed Dec 19 17:06:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08726 for ; Wed, 19 Dec 2001 17:06:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16GoqI-000GMN-00 for multi6-data@psg.com; Wed, 19 Dec 2001 14:05:38 -0800 Received: from mail3.microsoft.com ([131.107.3.123]) by psg.com with esmtp (Exim 3.33 #1) id 16GoqH-000GMG-00 for multi6@ops.ietf.org; Wed, 19 Dec 2001 14:05:37 -0800 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 19 Dec 2001 14:05:36 -0800 Received: from 157.54.5.25 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 19 Dec 2001 14:05:36 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 19 Dec 2001 14:05:36 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 19 Dec 2001 14:05:36 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Wed, 19 Dec 2001 14:04:00 -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="US-ASCII" Subject: RE: (multi6) requirements draft comments Date: Wed, 19 Dec 2001 14:04:00 -0800 Message-ID: Thread-Topic: (multi6) requirements draft comments Thread-Index: AcGIuS+POQn5OIibTkyfcFeM5aVwZgAH9aeQ From: "Christian Huitema" To: "J. Noel Chiappa" , X-OriginalArrivalTime: 19 Dec 2001 22:04:00.0715 (UTC) FILETIME=[1060E1B0:01C188D9] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA08726 > What's more interesting is to think about what happens when there's a > failure. This is *not* a situation that K-K talks about - they are simply > analyzing the most efficient naming hiearchy for optimal (in terms of > minimum table size) routing. Isn't it the case that, in order to maintain optimality in the face of a graph change, you have to entirely revisit your aggregation structure, which would be akin to renumbering the Internet? -- Christian Huitema From owner-multi6@ops.ietf.org Wed Dec 19 17:25:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09228 for ; Wed, 19 Dec 2001 17:25:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Gp9X-000Gsu-00 for multi6-data@psg.com; Wed, 19 Dec 2001 14:25:31 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16Gp9W-000Gso-00 for multi6@ops.ietf.org; Wed, 19 Dec 2001 14:25:30 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16Gp9W-000DLm-00 for multi6@ops.ietf.org; Wed, 19 Dec 2001 14:25:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200112192222.RAA06191@ginger.lcs.mit.edu> Date: Wed, 19 Dec 2001 17:22:42 -0500 From: "J. Noel Chiappa" To: multi6@ops.ietf.org Subject: RE: (multi6) requirements draft comments Cc: jnc@ginger.lcs.mit.edu Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Tony Hain" > So there is a prefix for every combination of possible providers a > customer can subscribe from No - at least not the way you seem to be meaning when you say those words). I.e. you seem to think everyone with service from Verizon DSL and Cox Cable would share the same prefix - which is distinctly not what I meant. What I meant was that all the people who are connected to both: - i) the same segment of the York County Cox CATV system here in Virginia, and - ii) the same Verizon DSL office would share the same one-level-up topological naming entity - and that would be a very different one-level-up topological naming entity from the people who have Cox CATV service in, say, Maryland, and who are also getting Verizon DSL service from an office there. Anyone thinking about anything related to routing needs to take a sharp implement, and engrave on their forehead "REAL TOPOLOGY IS KING". For routing, the *only* thing that matters is *actual* connectivity; i.e. the actual wires and routers. I often hear people *claim* they are paying attention to this - but then they go off and say things which show clearly that they haven't *really* understood it (and taken it to heart). Just because two wires are owned by the same company doesn't mean a damn thing. The only thing that matters is the real network topology - i.e. the graph of the real, physical assets that make up the network. The other thing that people need to keep firmly in mind is the K-K lesson, which is that the way you get the routing to scale, even in mindbogglingly large networks, is to use LOTS OF LAYERS OF ABSTRACTION. Three or four real layers of abstraction for a network of 10^8 nodes is *not* going to cut it. > How would the providers know where the overlaps are to route correctly, > ... How would routing work if those overlap areas were discontiguous? Some of these questions seem to be based on your incorrect understanding of what I was proposing. Both of these questions make no sense if each area of overlap has a (globally) unique Sij name (but one which may itself be subsumed in the name of a one-level-higher topology aggregate). > This approach moves the scaling problem from the technical space to the > administrative space, where the complexity would create prohibitive > costs. No, I was speaking of a system that basically automically assigned routing-names, and did so basically *purely* on the basis of connectivity; i.e. it would deduce for itself where to put abstraction naming boundaries. The *last* thing I want is bureacrats trying to do it. No doubt this would not sit well with the providers, but I don't mind waiting for the tide to cover their thrones. Noel From owner-multi6@ops.ietf.org Wed Dec 19 17:42:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09571 for ; Wed, 19 Dec 2001 17:42:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16GpPR-000HKT-00 for multi6-data@psg.com; Wed, 19 Dec 2001 14:41:57 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.33 #1) id 16GpPQ-000HKN-00 for multi6@ops.ietf.org; Wed, 19 Dec 2001 14:41:57 -0800 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id RAA06294; Wed, 19 Dec 2001 17:41:55 -0500 Date: Wed, 19 Dec 2001 17:41:55 -0500 From: "J. Noel Chiappa" Message-Id: <200112192241.RAA06294@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: RE: (multi6) requirements draft comments Cc: jnc@ginger.lcs.mit.edu Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: "Christian Huitema" > Isn't it the case that, in order to maintain optimality in the face of > a graph change, you have to entirely revisit your aggregation > structure, which would be akin to renumbering the Internet? First, you'd only have to renumber if you wanted to to maintain absolute optimality. Since absolute optimality produces a routing table of size e*ln(N), i.e. as I mentioned before a 60 entry routing table for a 10^8 node network, somehow I don't think we have to maintain absolute optimality! Second (and this is really irrelevant, given the point above, but in true routing-graph-theory-geek style I mention it for completeness) I expect that the vast majority of connectivity changes in a graph can be handled with a renumbering over a scope that's less than global. Noel From owner-multi6@ops.ietf.org Wed Dec 19 18:42:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10350 for ; Wed, 19 Dec 2001 18:42:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16GqIV-000Im2-00 for multi6-data@psg.com; Wed, 19 Dec 2001 15:38:51 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.33 #1) id 16GqIU-000Ilw-00 for multi6@ops.ietf.org; Wed, 19 Dec 2001 15:38:50 -0800 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id SAA06359; Wed, 19 Dec 2001 18:38:48 -0500 Date: Wed, 19 Dec 2001 18:38:48 -0500 From: "J. Noel Chiappa" Message-Id: <200112192338.SAA06359@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: (multi6) requirements draft comments Cc: jnc@ginger.lcs.mit.edu Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Michael Richardson > I believe that there are three solution spaces: > 1) ... if you have geographically relevant addressing, either via > geo-PI ... This is more or less the BGP solution space. > 2) network layer solutions. > mobile-IP like systems. > ... > opportunistic-encryption-like-tunnel systems. > ... > HIP-like systems- a variation of the above where IP addresess > become meaningless, and hashes of public keys terminate > connections. > 3) transport layer solutions. > Just use SCTP for everything I've been thinking about this in the back of my mind, and I see a somewhat different way to divide the solution space (perhaps related to looking at it architecturally, rather than from a mechanism point of view). The first split I come to is between "let the routing do it", and "use multiple routing-names". What I mean by this is that either: - i) you have, *and retain*, a single routing-name, and the routing has to somehow keep track of where it is / how to get to it, or - ii) you somehow use multiple different routing-names In other messages in the thread, I've been exploring stuff about the "have the routing do it" path. Here I'd like to expand some on the "use multiple routing-names" option. The first thing you have to settle is "how do higher level things (which could be either a transport protocol, or an application) keep track of who they are talking to"? Again, there are two ways to go: i) those things can be aware of the fact that the thing is now at a new and/or more than one routing-name (and I recall a proposal by Dave Crocker to the CIDRD WG some years back that proposed just this - he wanted a way to take one end of a TCP connection and rehome it from one IP address to another), or ii) those things can have some other way of referring to the thing they are talking to, and somewhere "else" in the software, that thing gets mapped to multiple routing-names. There are a multitude of ways to do the latter, depending on at what layer in the system the alternative name exists. - Classic mobile IP says that the "true" name is an internetwork address (which also doubles as a rendezvous point), and that maps to one or more "real" routing-names. - HIP creates a new namespace, roughly at the tranport level, and uses that. - SCTP again creates a new namespace, but at slightly higher level, closer to the application. Etc, etc... The interesting thing in all this is that mobility and multi-homing wind up both a) using much the same breakdown, and therefore b) potentially using very similar mechanisms. You can take that "architectural decision tree" above, and substitute "mobility" for "multi-homing" in it, and it will look basically indentical. So perhaps there's some place for a certain common mechanism? It also highlights some issues with some possible solutions. E.g. as I mentioned in a message to the IETF list, regarding mobile IP, tying the rendezvous to the original topological location of the host does have potential failure modes (e.g. if that part of the network goes unreachable, the mobile host may become unreachable even if it's still online elsewhere) This is doubly true of multi-homing stuff. If a multi-homed and/or mobile node has an address which is related to its "primary" ISP, and that ISP becomes unreachable, the node will perforce also be unreachable. > None of these solutions are even exclusive. I can see all three systems > occuring at the same time. Yes, but... if you have a solution which works for 10^7 multi-homed houses, and works well, why bother to have a separate one for companies? Noel From owner-multi6@ops.ietf.org Wed Dec 19 19:44:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11074 for ; Wed, 19 Dec 2001 19:44:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16GrJl-000Juk-00 for multi6-data@psg.com; Wed, 19 Dec 2001 16:44:13 -0800 Received: from nox.sandelman.ottawa.on.ca ([192.139.46.6] helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 3.33 #1) id 16GrJk-000Jue-00 for multi6@ops.ietf.org; Wed, 19 Dec 2001 16:44:12 -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 fBK0i8D08896 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Wed, 19 Dec 2001 19:44:11 -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 fBK0hxh19902 for ; Wed, 19 Dec 2001 19:44:03 -0500 (EST) Message-Id: <200112200044.fBK0hxh19902@marajade.sandelman.ottawa.on.ca> To: multi6@ops.ietf.org Subject: Re: (multi6) requirements draft comments In-reply-to: Your message of "Wed, 19 Dec 2001 18:38:48 EST." <200112192338.SAA06359@ginger.lcs.mit.edu> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 19 Dec 2001 19:43:58 -0500 From: Michael Richardson Sender: owner-multi6@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "J" == J Noel Chiappa writes: mcr> None of these solutions are even exclusive. I can see all three mcr> systems occuring at the same time. J> Yes, but... if you have a solution which works for 10^7 multi-homed J> houses, and works well, why bother to have a separate one for J> companies? If we can find a way to multihome 10^7 sites using a single route-name, then I'm all for it. (In my mind, this means that applications need not be aware they are multihomed, and some transport protocols would not care either) If the 10^7 can only be solved using your category (ii) solutions, then the traditional multihoming solutions will remain. ] 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"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPCE0TIqHRg3pndX9AQHF6AP/bUwIqUdSKZK1Vip8OsKVJs1SYUlaFWA0 8O/z3S3cujrXlCPZ1FM2yZYLertdvt/ScMkuicdD7i5UsHV3zlSENiEq5T/aA+uC CuJ6SZ9aYy9mXIsF+zJDxAZDlFBIS3H+4TDRn/7ZsMWkQB92UwcdQH2gj9IPusU+ YvrTizlWDMs= =mDYJ -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Wed Dec 19 19:44:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11087 for ; Wed, 19 Dec 2001 19:44:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16GrJV-000JuX-00 for multi6-data@psg.com; Wed, 19 Dec 2001 16:43:57 -0800 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by psg.com with esmtp (Exim 3.33 #1) id 16GrJU-000JuR-00 for multi6@ops.ietf.org; Wed, 19 Dec 2001 16:43:56 -0800 Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id fBK0hf620953 for ; Wed, 19 Dec 2001 16:43:41 -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 fBK0htW28002 for ; Wed, 19 Dec 2001 16:43:55 -0800 (PST) Message-Id: <5.1.0.14.2.20011219162034.00b16ec8@lint.cisco.com> X-Sender: elear@lint.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 19 Dec 2001 16:43:51 -0800 To: multi6@ops.ietf.org From: Eliot Lear Subject: comments on the requirements draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-multi6@ops.ietf.org Precedence: bulk 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: > A new IPv6 multihoming architecture MUST scale to accommodate orders > of magnitude more multi-homed sites without imposing unreasonable > requirements on the routing system. This is redundant. Sections 3.2.2 and 3.2.3 presume a real installed base. There is none. 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. Good luck, Eliot From owner-multi6@ops.ietf.org Wed Dec 19 22:45:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14647 for ; Wed, 19 Dec 2001 22:45:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Gu7E-000NN3-00 for multi6-data@psg.com; Wed, 19 Dec 2001 19:43:28 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.33 #1) id 16Gu7C-000NMv-00 for multi6@ops.ietf.org; Wed, 19 Dec 2001 19:43:26 -0800 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id WAA06852; Wed, 19 Dec 2001 22:43:23 -0500 Date: Wed, 19 Dec 2001 22:43:23 -0500 From: "J. Noel Chiappa" Message-Id: <200112200343.WAA06852@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: (multi6) requirements draft comments Cc: jnc@ginger.lcs.mit.edu Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: smd@ebone.net (Sean Doran) > PI and PA are absolutely _awful_ terms that should be uninvented in > favour of something that admits the truth that the optimal choice of > numbers is driven by MATH and not by economics, and would clear up > confusion among the various competing aggregation root and > number-assignment proposals. I've always deeply hated the terms "provider-based", "provider-independent", "provider-dependent", and their variants. (I have this sneaky suspicion that they were invented by people who didn't like some of the side-effects of CIDR, and tried [unsuccessfully] to stop it by creating loaded terminology to make it sound bad.) For the uninitiated (read "most of the world"), it makes it sound like it's purely a policy decision as to whether addresses are PI or not, and so it's "clear" to them that one should use PI, since the non-PI alternative provides lock-in to the ogre providers... I have tried to get people to use the term "connectivity-based", which is simple and clear, and accurately conveys what's going on - which is that your address is based on where you are connected. (This is actually also a more accurate technical description, since it covers both provider-based and exchange-based addressing systems [metro is an exchange-based system, BTW]). However, I've had little luck. Perhaps it's worth another try now... ;-) Noel PS: A side benefit of this is that "provider-independent addresses" becomes "connectivity-independent addresses", which in its oxymoronicity gives an immediate read on how silly the concept is. Kind of like "location independent street address". From owner-multi6@ops.ietf.org Wed Dec 19 23:37:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15359 for ; Wed, 19 Dec 2001 23:37:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Guwq-000OLb-00 for multi6-data@psg.com; Wed, 19 Dec 2001 20:36:48 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.33 #1) id 16Guwp-000OLV-00 for multi6@ops.ietf.org; Wed, 19 Dec 2001 20:36:47 -0800 Received: from [128.177.194.119] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 7DDC831926; Wed, 19 Dec 2001 20:36:46 -0800 (PST) User-Agent: Microsoft-Entourage/10.0.0.1331 Date: Wed, 19 Dec 2001 20:36:52 -0800 Subject: Re: (multi6) requirements draft comments From: David Conrad To: "J. Noel Chiappa" , multi6 Message-ID: In-Reply-To: <200112200343.WAA06852@ginger.lcs.mit.edu> 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 Noel, On 12/19/01 7:43 PM, "J. Noel Chiappa" wrote: > (I have this sneaky suspicion that they were invented by people who didn't > like some of the side-effects of CIDR, and tried [unsuccessfully] to stop it > by creating loaded terminology to make it sound bad.) Actually, no. The terms (coined, I believe, by Daniel Karrenberg) were intended merely to be descriptive. All the folks writing 2050 were pretty strongly in favor of CIDR. > For the uninitiated (read "most of the world"), it makes it sound like it's > purely a policy decision as to whether addresses are PI or not, and so it's > "clear" to them that one should use PI, since the non-PI alternative provides > lock-in to the ogre providers... At the time 2050 was being written, it was a (mostly) policy based decision -- ISPs hadn't yet decided that PI space was something they could tell their customers they wouldn't route. > However, I've had little luck. Perhaps it's worth another try now... ;-) So can I sign you up for helping on the revision of 2050? :-) > PS: A side benefit of this is that "provider-independent addresses" becomes > "connectivity-independent addresses", which in its oxymoronicity gives an > immediate read on how silly the concept is. Kind of like "location > independent street address". Were that this were true. Are you forgetting IP addresses are (currently) both routing names as well as endpoint identifiers? Connectivity-independent addresses is only oxymoronic if you assume the only use address space has is in the context of routability. Perhaps surprisingly, this was (is?) not always the case. There were many (*many*) organizations that were not interested in routing the addresses but who were interested in global uniqueness. No, really. I'm not making this up. As to why the RIRs would even consider allocating such addresses, see RFC 1814. Rgds, -drc From owner-multi6@ops.ietf.org Thu Dec 20 05:16:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04933 for ; Thu, 20 Dec 2001 05:16:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16H09J-0005mM-00 for multi6-data@psg.com; Thu, 20 Dec 2001 02:10:01 -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 16H09I-0005mC-00 for multi6@ops.ietf.org; Thu, 20 Dec 2001 02:10:00 -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 LAA09334; Thu, 20 Dec 2001 11:09:57 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA65106 from ; Thu, 20 Dec 2001 11:09:55 +0100 Message-Id: <3C21B8F4.CDFB960C@hursley.ibm.com> Date: Thu, 20 Dec 2001 11:09:56 +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: Eliot Lear Cc: multi6@ops.ietf.org Subject: Re: comments on the requirements draft References: <5.1.0.14.2.20011219162034.00b16ec8@lint.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Eliot Lear wrote: ... > Sections 3.2.2 and 3.2.3 presume a real installed base. There is none. No, they recognise the existence of a significant number of implementations. I work with development managers for host stacks, and I guarantee you they are not about to start over - multihoming has to be an add-on, if you want it to happen. I presume the same is true of router code. To me these are absolutely key requirements if you want multi6 to have any impact on the real world. Brian From owner-multi6@ops.ietf.org Thu Dec 20 10:47:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09916 for ; Thu, 20 Dec 2001 10:47:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16H5Oc-000Dgh-00 for multi6-data@psg.com; Thu, 20 Dec 2001 07:46:10 -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 16H5Ob-000DgO-00 for multi6@ops.ietf.org; Thu, 20 Dec 2001 07:46:09 -0800 content-class: urn:content-classes:message Subject: RE: comments on the requirements draft Date: Thu, 20 Dec 2001 07:45:05 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405DE0A@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: comments on the requirements draft X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Index: AcGJQbFWHS9PGoYuTO2jj3gUhdxBQwAKk3nA From: "Michel Py" To: "Brian E Carpenter" , "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 KAA09916 >>>> Eliot Lear wrote: >>>> Sections 3.2.2 and 3.2.3 presume a real installed base. >>>> There is none. >> Brian E Carpenter wrote >> No, they recognise the existence of a significant number of >> implementations. I work with development managers for host >> stacks, and I guarantee you they are not about to start over >> - multihoming has to be an add-on, if you want it to happen. >> I presume the same is true of router code. There is even more constraints on routers / switches since some of them have might hardware tailored for IPv6 already, or in an advanced design phase. If a multi6 implementation was to require changes to be made to the IPv6 header and especially to the address fields, it would certainly encounter a lot of resistance, to say the least. >> To me these are absolutely key requirements if you want multi6 >> to have any impact on the real world. >> Brian I agree with Brian here. Michel. From owner-multi6@ops.ietf.org Thu Dec 20 10:57:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10167 for ; Thu, 20 Dec 2001 10:57:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16H5Z3-000Duz-00 for multi6-data@psg.com; Thu, 20 Dec 2001 07:56:57 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.33 #1) id 16H5Z2-000Dur-00 for multi6@ops.ietf.org; Thu, 20 Dec 2001 07:56:56 -0800 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id KAA08364; Thu, 20 Dec 2001 10:56:54 -0500 Date: Thu, 20 Dec 2001 10:56:54 -0500 From: "J. Noel Chiappa" Message-Id: <200112201556.KAA08364@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: (multi6) requirements draft comments Cc: jnc@ginger.lcs.mit.edu Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Michael Richardson >> Yes, but... if you have a solution which works for 10^7 multi-homed >> houses, and works well, why bother to have a separate one for >> companies? > If we can find a way to multihome 10^7 sites using a single route-name, > then I'm all for it. ??? I never implied that any routing-based solution would allow all 10^7 sites to use a single routing-name. Actually, we need to be a bit more precise here, because we are using the term "routing-name" to mean both the name-including-location of individual hosts, as well as the names for topology aggregates. So I was thinking (using the terminology of a previous message) that all the hosts in a particular set Sij of multihomed hosts would share an aggregate-routing-name (ARN hereinafter). The chunk of topology (let's call it the TA) referred to by that ARN would be grouped together with other topologically close aggregates, i.e. topologically neighbouring groups (each with their own ARN), and that collection (lets call it that TAA) given yet another ARN (let's call it an AARN). Recurse as needed. :-) The AARN would typically be one that allowed you to tell, simply from inspecting an ARN and the AARN, that the TA (i.e. the aggregate named by the ARN) was part of the TAA (i.e. the aggregate named by the AARN). Some of the other TA's in that TAA might also be Sij's (other Sij's, of course), but the TAA would almost certainly not be all Sij's - it would probably include the local uni-homed hosts, the S0J's and Si0's, as well. > If the 10^7 can only be solved using your category (ii) solutions I don't know which you're referring to here, since I used that numeration scheme twice. (Perhaps I should have used different ones.) But I think any of the approaches I laid out is probably viable in *architectural* terms - provided the *engineering* is done competently! Incompetent engineering will doom any approach: using the routing to track 10^7 hosts with flat addresses isn't going to work, but then again neither is using a DNS-type multi-homing/mobility system with a single, big, central server. How you pick among the approaches, well that's hard - you have to look at a) the costs and benefits of each architectural approach (e.g. using the host's home address as its rendezvous for mobility purposes means that if that part of the network goes offline, you can't reach the host), and b) the costs and benefits of viable engineering solutions. For example: My extensive comments on the routing stuff is simply intended to make clear to people what the "envelope" (in the airplane performance sense) of the viable engineering for routing-based approaches is. Now, perhaps other non-technical factors will rule out the only approaches which are viable in engineering terms. E.g. perhaps the providers won't accept having to give up control over address allocation. If so, that means all routing-based solutions to multi-homing/mobility are non-viable, so you'd have to look elsewhere. > (In my mind, this means that applications need not be aware they are > multihomed, and some transport protocols would not care either) That's a design decision - and a very important one - that people may well decide is the right way to go. But I wasn't trying to decide on a particular design, just trying to clarify what the choices were. Noel From owner-multi6@ops.ietf.org Thu Dec 20 11:09:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10485 for ; Thu, 20 Dec 2001 11:09:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16H5kx-000EDx-00 for multi6-data@psg.com; Thu, 20 Dec 2001 08:09:15 -0800 Received: from sj-msg-core-2.cisco.com ([171.69.24.11]) by psg.com with esmtp (Exim 3.33 #1) id 16H5kw-000EDr-00 for multi6@ops.ietf.org; Thu, 20 Dec 2001 08:09:14 -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 fBKG98s18380; Thu, 20 Dec 2001 08:09:08 -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 fBKG8f103810; Thu, 20 Dec 2001 08:08:41 -0800 (PST) Message-Id: <5.1.0.14.2.20011220080652.03b05100@lint.cisco.com> X-Sender: elear@lint.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 20 Dec 2001 08:08:38 -0800 To: Brian E Carpenter From: Eliot Lear Subject: Re: comments on the requirements draft Cc: multi6@ops.ietf.org In-Reply-To: <3C21B8F4.CDFB960C@hursley.ibm.com> References: <5.1.0.14.2.20011219162034.00b16ec8@lint.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-multi6@ops.ietf.org Precedence: bulk Then you're being penni-wise and pound foolish. If not deploying multihoming means we exceed Moore's law over some period of time, we're all in trouble. Let's evaluate solutions based on their technical merit, and not on the amount of code that will need to be written. Eliot At 11:09 AM 12/20/2001 +0100, Brian E Carpenter wrote: >Eliot Lear wrote: >... > > > Sections 3.2.2 and 3.2.3 presume a real installed base. There is none. > >No, they recognise the existence of a significant number of implementations. >I work with development managers for host stacks, and I guarantee you >they are not about to start over - multihoming has to be an add-on, if >you want it to happen. I presume the same is true of router code. > >To me these are absolutely key requirements if you want multi6 to have >any impact on the real world. > > Brian From owner-multi6@ops.ietf.org Thu Dec 20 11:38:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11802 for ; Thu, 20 Dec 2001 11:38:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16H6Bl-000F30-00 for multi6-data@psg.com; Thu, 20 Dec 2001 08:36:57 -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 16H6Bk-000F2u-00 for multi6@ops.ietf.org; Thu, 20 Dec 2001 08:36:56 -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 RAA06934; Thu, 20 Dec 2001 17:36:53 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA56230 from ; Thu, 20 Dec 2001 17:36:52 +0100 Message-Id: <3C2213A5.F5196CD8@hursley.ibm.com> Date: Thu, 20 Dec 2001 17:36:53 +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: Eliot Lear Cc: multi6@ops.ietf.org Subject: Re: comments on the requirements draft References: <5.1.0.14.2.20011219162034.00b16ec8@lint.cisco.com> <5.1.0.14.2.20011220080652.03b05100@lint.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Eliot, In almost all cases I would agree with you. And it may well be that 5 or 10 years from now, people will have got enough revenue from IPv6, or will have such compelling customer input, that they rewrite their stacks for multihoming. But in the 0 to 5 year timeframe, I don't expect stacks to get rewritten. Brian Eliot Lear wrote: > > Then you're being penni-wise and pound foolish. If not deploying > multihoming means we exceed Moore's law over some period of time, we're all > in trouble. Let's evaluate solutions based on their technical merit, and > not on the amount of code that will need to be written. > > Eliot > > At 11:09 AM 12/20/2001 +0100, Brian E Carpenter wrote: > >Eliot Lear wrote: > >... > > > > > Sections 3.2.2 and 3.2.3 presume a real installed base. There is none. > > > >No, they recognise the existence of a significant number of implementations. > >I work with development managers for host stacks, and I guarantee you > >they are not about to start over - multihoming has to be an add-on, if > >you want it to happen. I presume the same is true of router code. > > > >To me these are absolutely key requirements if you want multi6 to have > >any impact on the real world. > > > > Brian From owner-multi6@ops.ietf.org Thu Dec 20 11:46:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11954 for ; Thu, 20 Dec 2001 11:46:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16H6Ka-000FIE-00 for multi6-data@psg.com; Thu, 20 Dec 2001 08:46:04 -0800 Received: from mail4.microsoft.com ([131.107.3.122]) by psg.com with esmtp (Exim 3.33 #1) id 16H6KZ-000FI4-00 for multi6@ops.ietf.org; Thu, 20 Dec 2001 08:46:03 -0800 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.154]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 20 Dec 2001 08:46:02 -0800 Received: from 157.54.6.150 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 20 Dec 2001 08:46:03 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 20 Dec 2001 08:46:01 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 20 Dec 2001 08:46:02 -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, 20 Dec 2001 08:44:26 -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="US-ASCII" Subject: RE: (multi6) requirements draft comments Date: Thu, 20 Dec 2001 08:44:25 -0800 Message-ID: Thread-Topic: (multi6) requirements draft comments Thread-Index: AcGJcIAMRGsHKbyzRmqaFuYCjaDHjwAAylTQ From: "Christian Huitema" To: "J. Noel Chiappa" , X-OriginalArrivalTime: 20 Dec 2001 16:44:26.0195 (UTC) FILETIME=[95E31230:01C18975] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA11954 > >> Yes, but... if you have a solution which works for 10^7 multi-homed > >> houses, and works well, why bother to have a separate one for > >> companies? > > > If we can find a way to multihome 10^7 sites using a single route- > name, > > then I'm all for it. > > ??? I never implied that any routing-based solution would allow all 10^7 > sites to use a single routing-name. I think that when evaluating any proposal, we should try to define how it scales by using standard complexity analysis. I can myself see at least two interesting variables: 1) The number S of multi-homed sites 2) The number H of "homes" for a given site There are multiple aspects of scaling, and we should review them. Among the interesting variables are: - The impact of multi-homing on multi-homed hosts, - The impact of multi-homing on "correspondent" hosts, - The impact of multi-homing on Internet routers, - The impact of multi-homing on "site exit" routers. Different solutions have different characteristics. The so-called "PI" solution, for example, has an O(1) impact on multi-homed hosts and correspondent hosts, an O(H) impact on site exit routers, and an O(S) impact on Internet routers. The "host centric" solution that I put forward has an O(H) impact on hosts, correspondent hosts, and site exit routers; and the same impact on routers as standard routing, i.e. in theory O(log S), or maybe O(log S + log H). Expressing the complexity in these terms helps us understand the impact of various scenarios, e.g. "what if every home network is multi-homed", or "what if every site decides to have 100 providers"... -- Christian Huitema From owner-multi6@ops.ietf.org Thu Dec 20 13:47:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16303 for ; Thu, 20 Dec 2001 13:47:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16H8Bl-000HfJ-00 for multi6-data@psg.com; Thu, 20 Dec 2001 10:45:05 -0800 Received: from evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net ([4.60.69.141] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.33 #1) id 16H8Bk-000Hf8-00 for multi6@ops.ietf.org; Thu, 20 Dec 2001 10:45:04 -0800 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Thu, 20 Dec 2001 10:44:56 -0800 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 589E1362F52542FB8D586CC3C6C9EC4D for plus 1 more; Thu, 20 Dec 2001 10:44:56 -0800 From: "Tony Hain" To: "J. Noel Chiappa" , Subject: RE: (multi6) requirements draft comments Date: Thu, 20 Dec 2001 10:39: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) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <200112192222.RAA06191@ginger.lcs.mit.edu> X-SLUIDL: 39E54EB1-EF6D4BB9-B7AEF5F1-349C2EB7 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit J. Noel Chiappa wrote: > No - at least not the way you seem to be meaning when you say > those words). > I.e. you seem to think everyone with service from Verizon DSL > and Cox Cable > would share the same prefix - which is distinctly not what I meant. > > What I meant was that all the people who are connected to both: > > - i) the same segment of the York County Cox CATV system here > in Virginia, > and > - ii) the same Verizon DSL office Just checking, because you distinctly claimed a difference from metro, but in your example you have an implicit metro context. > Anyone thinking about anything related to routing needs to > take a sharp > implement, and engrave on their forehead "REAL TOPOLOGY IS > KING". For routing, > the *only* thing that matters is *actual* connectivity; i.e. > the actual wires > and routers. ... > The other thing that people need to keep firmly in mind is > the K-K lesson, > which is that the way you get the routing to scale, even in > mindbogglingly > large networks, is to use LOTS OF LAYERS OF ABSTRACTION. I am sure you are well aware of the contradiction in those two statements in the abstract, and the fact that the latter is why people frequently loose focus on the former. The piece that sits in between those two viewpoints of the world is the practical reality of the routing protocol technology and the application of that by mere mortal (though frequently sub-human) operators. Yes we need to focus on real topology, but practical reality of current technology says that we need to constrain the degrees in freedom to something managable. We know how to aggregate when all the end sites play nice and constrain their service to a single ISP, but they refuse to do that. We also know how to implement a scalable metro approach, but ISPs refuse to do that. Since the end sites are the holders of the money, the ISPs will eventually loose this battle, and lacking any revolutionary technology will have to implement some degree of metro. My suggestion is that they do this as an overlay to the PA system so they get the best of both worlds. Tony From owner-multi6@ops.ietf.org Thu Dec 20 15:35:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19731 for ; Thu, 20 Dec 2001 15:35:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16H9tL-000Jkc-00 for multi6-data@psg.com; Thu, 20 Dec 2001 12:34:11 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.33 #1) id 16H9tK-000JkV-00 for multi6@ops.ietf.org; Thu, 20 Dec 2001 12:34:11 -0800 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id PAA08934; Thu, 20 Dec 2001 15:34:08 -0500 Date: Thu, 20 Dec 2001 15:34:08 -0500 From: "J. Noel Chiappa" Message-Id: <200112202034.PAA08934@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: RE: (multi6) requirements draft comments Cc: jnc@ginger.lcs.mit.edu Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: "Tony Hain" >> What I meant was that all the people who are connected to both: >> - i) the same segment of the York County Cox CATV system here >> in Virginia, >> and >> - ii) the same Verizon DSL office > you distinctly claimed a difference from metro, but in your example you > have an implicit metro context. You clipped the next line: > would share the same one-level-up topological naming entity Let me try this another way. Let's define a "chunk" of a graph as a set of nodes, and the arcs between them, such that you can get from any node to any other node by traversing only nodes and arcs that are part of the chunk. In the map (graph) of the network, I can then replace that "chunk" of the map/graph with a single node representing that "chunk"; i.e. draw a new, simpler map/graph with one node where all those nodes used to be. This process can recurse; i.e. I can define some "meta-chunks", and draw yet another map/graph. (You can fine a picture of some of this process here: http://users.exis.net/~jnc/tech/routing_slides.html Look for the header "Abstraction Hierarchies", and then look at the second diagram. I guess I should add a picture showing the simplified graph, but I assumed it's pretty obvious what it looks like.) Now, what I was doing above is taking a map (graph, actually) of the real network, including all these houses Hk which might be multi-homed, and trying to draw (nested) circles around portions of that actual connectivity map/graph, that define "chunks" of the map/graph which are useful for making the routing scale. I have defined a particular "chunk", the set of end-nodes Sij, as ecompassing the following nodes in that map/graph: the node for that particular cable installation from that cable provider, Ci (I say "that particular .. installation", since other cable installations belonging to that company are elsewhere in the map), the node for that DSL office from DSL provider, Dj (same comment - their other offices are elsewhere in the map/graph), and all the host nodes Hk such that any Hk has a link to both Ci and Dj, along with all the arcs among them. Now, do the same thing for all the other local ISP's hardware segments, and the customers who are connected to them, producing a map/graph with a "simplified" representation of the connectivity in the local area. I can now recurse this process, and group things into even bigger aggregates. The *key* difference here from metro is that I *start* with the actual connectivity map, placing no constraints on how it is connected. (E.g. there may be no direct link from Ci to Dj, except through the customer nodes - which of course do not forward traffic.) From that, I then asssign addresses. This is very different from metro, which assigns addresses to things, and then places constraints on how things can be connected - and never changes the addresses no matter how the actual connectivity changes. For instance, notice that if customer Hk drops cable provider Ci and signs up with a new provider, Cq, they get a new address, since they are now part of the set Sqj. This is distinctly different from what metro addressing does. >> "REAL TOPOLOGY IS KING". For routing, the *only* thing that matters is >> *actual* connectivity; i.e. the actual wires and routers. >> ... >> the K-K lesson, which is that the way you get the routing to scale, >> even in mindbogglingly large networks, is to use LOTS OF LAYERS OF >> ABSTRACTION. > I am sure you are well aware of the contradiction in those two > statements in the abstract There is no contradiction. Perhaps you are being confused by my terminology, where I am using the term "abstraction" in the graph sense, not the software engineering sense. I use the term "abstraction" of (sub) graph to mean a simplified representation of a "chunk" of a graph - but not *neceessarily* one that can be produced by any repeated replacement of smaller sub-"chunks" of the "chunk" with nodes (that process, and the results, I tend to call "aggregation"). Let me give you a concrete example. Suppose I am a small ISP, with 5 routers total, four of them border routers, A-D, and one internal router I. I have 4 links, directly connecting each border router to I. Here are some "simplified" representations of that "chunk" of the map/graph that you can't produce by an aggregation process: - a graph in which all four border nodes are connected to each other directly - a graph in which the four border routers are connected in a ring (i.e. A to B, B to C, etc) So I tend to use the word "abstraction" to mean what most people mean by "aggregation", but as a more encompassing technical process. In particular, in their scaling work, Kleinrock-Kamoun uses only "aggregation" (as defined here) steps to produce simplified graphs. > We know how to aggregate when all the end sites play nice and constrain > their service to a single ISP, but they refuse to do that. We also know > how to implement a scalable metro approach, but ISPs refuse to do that. > Since the end sites are the holders of the money, the ISPs will > eventually loose this battle, and lacking any revolutionary technology > will have to implement some degree of metro. That may well be. FWIW, the addressing approach I have outlined allows both the users to multihome, and the ISP's not to have to be forced to interconnect - but it does it by using address allocation mechanisms that both sides may not like: the users have to renumber when they change providers, and the ISP's have to give up some control over addressing. However, I have no way to control what the market will do - and indeed, my addressing scheme may not even be an option for people. I'm simply trying to explain to people what's fundamentally possible from the routing side. Noel From owner-multi6@ops.ietf.org Thu Dec 20 16:31:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21216 for ; Thu, 20 Dec 2001 16:31:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16HAke-000KsK-00 for multi6-data@psg.com; Thu, 20 Dec 2001 13:29:16 -0800 Received: from mail2.microsoft.com ([131.107.3.124]) by psg.com with esmtp (Exim 3.33 #1) id 16HAke-000KsE-00 for multi6@ops.ietf.org; Thu, 20 Dec 2001 13:29:16 -0800 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 20 Dec 2001 13:29:15 -0800 Received: from 157.54.6.197 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 20 Dec 2001 13:29:15 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 20 Dec 2001 13:29:14 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 20 Dec 2001 13:29:14 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Thu, 20 Dec 2001 13:27:38 -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="US-ASCII" Subject: RE: (multi6) requirements draft comments Date: Thu, 20 Dec 2001 13:27:37 -0800 Message-ID: Thread-Topic: (multi6) requirements draft comments Thread-Index: AcGJl4amsylCziRNQAuspnFpZ/0h5wABGSBQ From: "Christian Huitema" To: "J. Noel Chiappa" , X-OriginalArrivalTime: 20 Dec 2001 21:27:38.0002 (UTC) FILETIME=[25CB0F20:01C1899D] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA21216 > FWIW, the addressing approach I have outlined allows both the users to > multihome, and the ISP's not to have to be forced to interconnect - but it > does it by using address allocation mechanisms that both sides may not > like: > the users have to renumber when they change providers, and the ISP's have > to > give up some control over addressing. This control issue limits the type of aggregation that we can adopt, in the sense that aggregates have to somehow match the ownership of resource. Once we take this constraint into account, it is very unclear that we can devise an addressing plan that matches the arbitrary graph resulting of multi-homing. The control issue is also the rubbing point in explicit routing solutions. Typically, providers don't want users to decide which of the provider's resource will or will not be used by a particular set of packets. In fact, this is one of the reasons I like the model of having multiple addresses for multi-homed sites: by choosing the address explicitly, the end users can get some of the benefits of explicit routing. -- Christian Huitema From owner-multi6@ops.ietf.org Thu Dec 20 16:52:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21763 for ; Thu, 20 Dec 2001 16:52:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16HB4c-000LHx-00 for multi6-data@psg.com; Thu, 20 Dec 2001 13:49:54 -0800 Received: from evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net ([4.60.69.141] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.33 #1) id 16HB4c-000LHq-00 for multi6@ops.ietf.org; Thu, 20 Dec 2001 13:49:54 -0800 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Thu, 20 Dec 2001 13:49:49 -0800 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id AF75006F285543B5B2EFE30257A6F401 for plus 1 more; Thu, 20 Dec 2001 13:49:48 -0800 From: "Tony Hain" To: "J. Noel Chiappa" , Subject: RE: (multi6) requirements draft comments Date: Thu, 20 Dec 2001 13:44:45 -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) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <200112202034.PAA08934@ginger.lcs.mit.edu> X-SLUIDL: 3FD5335B-54754212-8D9DFC9C-E847F3A5 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit J. Noel Chiappa wrote: > > have an implicit metro context. > > You clipped the next line: > > > would share the same one-level-up topological naming entity Sorry I should have been more precise. There is an implicit geographic context which modifies the scope of the topology graph. > (You can fine a picture of some of this process here: > > http://users.exis.net/~jnc/tech/routing_slides.html Your picture is too simple to be useful in addressing the scope of this problem. Consider that A3 is connected to 'other stuff'. Your subsiquent abstraction to X would still be valid, but depending on where in 'other stuff' that connection occured you might get different answers for the topology name of X, yet the abstraction is too simple to explain why. > Now, do the same thing for all the other local ISP's hardware ^^^^^ This focus on *local* is the basic problem. The actual topology frequently connects both at some local level and pulls in a few very remote ISPs. Consider MegaRandomCorp which has connections to 6 ISPs in the SF area, but on the same set of border routers has direct circuits to an ISP in London, Tokyo, and Sydney. At the same time RandomMegaCorp has connections to 3 of the same SF, Tokyo, and Sydney ISPs, but a different one in London. > The *key* difference here from metro is that I *start* with the actual > connectivity map, placing no constraints on how it is > connected. (E.g. there > may be no direct link from Ci to Dj, except through the > customer nodes - > which of course do not forward traffic.) From that, I then > asssign addresses. If you fold the above complexity into your graph along with the other ~12000 ASs that are prefix origins today, and managing the topology-names becomes an administrative burden as topology is constantly shifting. > the users have to renumber when they change providers, and Actually they have to renumber everytime their neighbors change providers as well, because the entire graph changes around them. Tony From owner-multi6@ops.ietf.org Thu Dec 20 20:47:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26558 for ; Thu, 20 Dec 2001 20:47:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16HEiS-0000TY-00 for multi6-data@psg.com; Thu, 20 Dec 2001 17:43:16 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.33 #1) id 16HEiR-0000TO-00 for multi6@ops.ietf.org; Thu, 20 Dec 2001 17:43:15 -0800 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id UAA09423; Thu, 20 Dec 2001 20:43:13 -0500 Date: Thu, 20 Dec 2001 20:43:13 -0500 From: "J. Noel Chiappa" Message-Id: <200112210143.UAA09423@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: RE: (multi6) requirements draft comments Cc: jnc@ginger.lcs.mit.edu Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: "Tony Hain" > There is an implicit geographic context which modifies the scope of the > topology graph. Only insofar as things which are topologically related often *happen* to have a geographical relationship. All the *network* cares about is that these things are next to each other in the connectivity graph. Their geographic co-location is an accident of which *no* use is made. > Your picture is too simple to be useful in addressing the scope of this > problem. It was simply intended as an example of the process of abstraction; I didn't mean that this particular example had anything to do with this case. >> Now, do the same thing for all the other local ISP's hardware > This focus on *local* is the basic problem. In that particular case, I was again speaking of local to mean "things which are topologically close, and by accident happen to be physically close". > The actual topology frequently connects both at some local level and > pulls in a few very remote ISPs. Consider MegaRandomCorp which has > connections to 6 ISPs in the SF area, but on the same set of border > routers has direct circuits to an ISP in London, Tokyo, and Sydney. At > the same time RandomMegaCorp has connections to 3 of the same SF, > Tokyo, and Sydney ISPs, but a different one in London. *It doesn't matter*. The resulting connectivity graph is still a graph, and K-K still applies. The naming abstraction boundaries you may have to create may not be ones that people are happy with for policy reasons, but K-K guarantees that even a network chock-a-block with the kind of connections you posit here can have efficient (in the sense of small routing tables) routing - *provided* that appropriate naming abstraction boundaries are picked. > If you fold the above complexity into your graph along with the other > ~12000 ASs that are prefix origins today, and managing the > topology-names becomes an administrative burden Which is why, if you want to do multi-homing purely with routing (i.e. multi-homed machines have a single routing-name, and the routing makes the "right thing" happen), routing-name assignment shouldn't be done manually, and why bureacracies to assign routing-names are problematic. > as topology is constantly shifting. >> the users have to renumber when they change providers > Actually they have to renumber everytime their neighbors change > providers as well, because the entire graph changes around them. I've already explained this point to Christian, but apparently I wasn't clear enough. Let me try again: >>> You'd only have to renumber if you wanted to to maintain absolute >>> optimality. Since absolute optimality produces a routing table of >>> size e*ln(N), i.e. as I mentioned before a 60 entry routing table for >>> a 10^8 node network, somehow I don't think we have to maintain >>> absolute optimality! So we can almost certainly maintain our required degree of routing table size limitation without constant renumbering. Yes, large changes (e.g. a local ISP connects up to a new national ISP) might cause some renumbering, but that's true even for uni-homed hosts. >>> Second (and this is really irrelevant, given the point above, but in >>> true routing-graph-theory-geek style I mention it for completeness) I >>> expect that the vast majority of connectivity changes in a graph can >>> be handled with a renumbering over a scope that's less than global. In other words, if you are trying (for some reason) to provide the optimal abstraction hierarchy, I would imagine that for most changes in the graph, creation of a new optimal abstraction hierarchy would require changes to only a reduced scope of the graph. Noel From owner-multi6@ops.ietf.org Thu Dec 20 21:26:14 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27074 for ; Thu, 20 Dec 2001 21:26:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16HFMn-0001O2-00 for multi6-data@psg.com; Thu, 20 Dec 2001 18:24:57 -0800 Received: from [65.174.124.5] (helo=miata.procket.com) by psg.com with esmtp (Exim 3.33 #1) id 16HFMm-0001Nw-00 for multi6@ops.ietf.org; Thu, 20 Dec 2001 18:24:56 -0800 Received: from alpha-tli.procket.com (IDENT:root@alpha-tli.procket.com [10.2.3.1]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id fBL2OmHb011901; Thu, 20 Dec 2001 18:24:48 -0800 (PST) Received: (from tli@localhost) by alpha-tli.procket.com (8.12.1/8.12.1) id fBL2OmMd022978; Thu, 20 Dec 2001 18:24:48 -0800 From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15394.40304.66918.881839@alpha-tli.procket.com> Date: Thu, 20 Dec 2001 18:24:48 -0800 To: "J. Noel Chiappa" Cc: multi6@ops.ietf.org Subject: RE: (multi6) requirements draft comments In-Reply-To: <200112210143.UAA09423@ginger.lcs.mit.edu> References: <200112210143.UAA09423@ginger.lcs.mit.edu> X-Mailer: VM 6.92 under Emacs 20.5.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit We do ourselves a disservice when we use the word 'optimal' because it is, in fact, not what we're after. We know that we can only have optimality if we have infinite information. There's a small scalability problem with that. What we need is an abstraction hierarchy that is 'good enough': the number of items at any level of the hierarchy never grows faster than Moore's law. Note that this is and will continue to be sufficiently challenging as it is. Tony From owner-multi6@ops.ietf.org Thu Dec 20 22:09:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28470 for ; Thu, 20 Dec 2001 22:09:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16HG39-0002EJ-00 for multi6-data@psg.com; Thu, 20 Dec 2001 19:08:43 -0800 Received: from hagx.ne.mediaone.net ([65.96.131.197] helo=perdition.linnaean.org) by psg.com with esmtp (Exim 3.33 #1) id 16HG38-0002Df-00 for multi6@ops.ietf.org; Thu, 20 Dec 2001 19:08:42 -0800 Received: by perdition.linnaean.org (Postfix, from userid 31013) id 931501B9FE; Thu, 20 Dec 2001 22:08:26 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "J. Noel Chiappa" Cc: multi6@ops.ietf.org Subject: RE: (multi6) requirements draft comments In-Reply-To: <200112210143.UAA09423@ginger.lcs.mit.edu> References: <200112210143.UAA09423@ginger.lcs.mit.edu> X-Mailer: VM 6.34 under Emacs 20.7.1 Reply-To: Daniel Hagerty From: Daniel Hagerty Date: Thu, 20 Dec 2001 22:08:26 -0500 Message-Id: <20011221030826.931501B9FE@perdition.linnaean.org> Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The naming abstraction boundaries you may have to create may not be > ones that people are happy with for policy reasons, but K-K > guarantees that even a network chock-a-block with the kind of > connections you posit here can have efficient (in the sense of > small routing tables) routing - *provided* that appropriate naming > abstraction boundaries are picked. In other words, a techinically proper routing layer implementation has some serious layer 9 issues to be resolved. From owner-multi6@ops.ietf.org Fri Dec 21 01:17:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02653 for ; Fri, 21 Dec 2001 01:17:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16HIvb-0005ZY-00 for multi6-data@psg.com; Thu, 20 Dec 2001 22:13:07 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16HIva-0005ZS-00 for multi6@ops.ietf.org; Thu, 20 Dec 2001 22:13:06 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16HIva-000EJP-00 for multi6@ops.ietf.org; Thu, 20 Dec 2001 22:13:06 -0800 Message-ID: <20011221003301.A14280@partan.com> References: <200112201556.KAA08364@ginger.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <200112201556.KAA08364@ginger.lcs.mit.edu>; from jnc@ginger.lcs.mit.edu on Thu, Dec 20, 2001 at 10:56:54AM -0500 Date: Fri, 21 Dec 2001 00:33:01 -0500 From: Andrew Partan To: "J. Noel Chiappa" Cc: multi6@ops.ietf.org Subject: Re: (multi6) requirements draft comments Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, Dec 20, 2001 at 10:56:54AM -0500, J. Noel Chiappa wrote: > Now, perhaps other non-technical factors will rule out the only approaches > which are viable in engineering terms. E.g. perhaps the providers won't > accept having to give up control over address allocation. I rather suspect the opposite - that providers will be happy to give up the horrible logistical bureaucratic nightmare that address allocation is. --asp From owner-multi6@ops.ietf.org Fri Dec 21 01:17:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02672 for ; Fri, 21 Dec 2001 01:17:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16HIxI-0005bR-00 for multi6-data@psg.com; Thu, 20 Dec 2001 22:14:52 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16HIxI-0005bL-00 for multi6@ops.ietf.org; Thu, 20 Dec 2001 22:14:52 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16HIxI-000EN0-00 for multi6@ops.ietf.org; Thu, 20 Dec 2001 22:14:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20011221003647.B14280@partan.com> References: <200112202034.PAA08934@ginger.lcs.mit.edu> In-Reply-To: ; from alh-ietf@tndh.net on Thu, Dec 20, 2001 at 01:44:45PM -0800 Date: Fri, 21 Dec 2001 00:36:47 -0500 From: Andrew Partan To: Tony Hain Cc: multi6@ops.ietf.org Subject: Re: (multi6) requirements draft comments Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, Dec 20, 2001 at 01:44:45PM -0800, Tony Hain wrote: > If you fold the above complexity into your graph along with the other > ~12000 ASs that are prefix origins today, and managing the > topology-names becomes an administrative burden as topology is > constantly shifting. No, not if the system does the work for you. Managing the topology abstractions is something the system should do, not people. > > the users have to renumber when they change providers, and > > Actually they have to renumber everytime their neighbors change > providers as well, because the entire graph changes around them. No, only if they change their attachment point. If your neighor changes his attachment point, he renumbers, not you. --asp From owner-multi6@ops.ietf.org Fri Dec 21 01:39:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04170 for ; Fri, 21 Dec 2001 01:39:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16HJI6-00066a-00 for multi6-data@psg.com; Thu, 20 Dec 2001 22:36:22 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16HJI5-00066U-00 for multi6@ops.ietf.org; Thu, 20 Dec 2001 22:36:21 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16HJHY-000Ezk-00; Thu, 20 Dec 2001 22:35:48 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Andrew Partan Cc: "J. Noel Chiappa" , multi6@ops.ietf.org Subject: Re: (multi6) requirements draft comments References: <200112201556.KAA08364@ginger.lcs.mit.edu> <20011221003301.A14280@partan.com> Message-Id: Date: Thu, 20 Dec 2001 22:35:48 -0800 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> perhaps the providers won't accept having to give up control over >> address allocation. > I rather suspect the opposite - that providers will be happy to > give up the horrible logistical bureaucratic nightmare that address > allocation is. it's a well known fantasy among those distant from operations that providers' business are enhanced by having to manage address space. randy From owner-multi6@ops.ietf.org Fri Dec 21 05:31:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21151 for ; Fri, 21 Dec 2001 05:31:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16HMw4-000AkF-00 for multi6-data@psg.com; Fri, 21 Dec 2001 02:29:52 -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 16HMw4-000Ak8-00 for multi6@ops.ietf.org; Fri, 21 Dec 2001 02:29:52 -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 LAA12140 for ; Fri, 21 Dec 2001 11:29:50 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA47820 from ; Fri, 21 Dec 2001 11:29:48 +0100 Message-Id: <3C230F1D.C185ECB1@hursley.ibm.com> Date: Fri, 21 Dec 2001 11:29:49 +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: multi6@ops.ietf.org Subject: Reqt. 3.1.1 [was Re: (multi6) requirements draft comments] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tony Hain wrote: ... > We also know how to > implement a scalable metro approach, but ISPs refuse to do that. Since > the end sites are the holders of the money, the ISPs will eventually > loose this battle, and lacking any revolutionary technology will have to > implement some degree of metro. My suggestion is that they do this as an > overlay to the PA system so they get the best of both worlds. OK, we don't discuss business models in the IETF, but this is the key issue in moving to any kind of *fixed* address alocation other than ISP based PA. ["fixed" is a relative term - I mean one that isn't automatically generated on the Noel model, not one that is fixed for all time.] The reason I've railed against Tony's PI proposal is because I have serious doubts whether market forces will lead to the adoption of metro (or metro-like) addressing and the consequent creation of ISP-neutral metro exchanges. But in any case, it's something totally outside the IETF's control. It's also completely compatible with PA addresses, simple by giving PA blocks to the metro exchanges if and when they appear. However, returning to our topic, that would make the metro exchanges key failure points in the multihoming system. That breaks requirement 3.1.1 in the draft. Do we want to insist that the solution MUST accommodate failure of metro exchanges? Brian From owner-multi6@ops.ietf.org Fri Dec 21 05:39:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21226 for ; Fri, 21 Dec 2001 05:39:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16HN4x-000Avo-00 for multi6-data@psg.com; Fri, 21 Dec 2001 02:39:03 -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 16HN4w-000Avf-00 for multi6@ops.ietf.org; Fri, 21 Dec 2001 02:39: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 LAA12386 for ; Fri, 21 Dec 2001 11:39:00 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA60738 from ; Fri, 21 Dec 2001 11:38:59 +0100 Message-Id: <3C231143.2E04812C@hursley.ibm.com> Date: Fri, 21 Dec 2001 11:38:59 +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: multi6@ops.ietf.org Subject: Missing DNS reqt? [was Re: (multi6) requirements draft comments] References: <200112202034.PAA08934@ginger.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "J. Noel Chiappa" wrote: ... > The *key* difference here from metro is that I *start* with the actual > connectivity map, placing no constraints on how it is connected. (E.g. there > may be no direct link from Ci to Dj, except through the customer nodes - > which of course do not forward traffic.) From that, I then asssign addresses. ...which then have to be reflected globally in the DNS before they can be used. This seems to be a real difficulty in automated address assignments. 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. Brian From owner-multi6@ops.ietf.org Fri Dec 21 10:52:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25439 for ; Fri, 21 Dec 2001 10:52:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16HRwg-000HQg-00 for multi6-data@psg.com; Fri, 21 Dec 2001 07:50:50 -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 16HRwf-000HQO-00 for multi6@ops.ietf.org; Fri, 21 Dec 2001 07:50:49 -0800 Subject: RE: Missing DNS reqt? [was Re: (multi6) requirements draft comments] Date: Fri, 21 Dec 2001 07:50:47 -0800 Message-ID: <2B81403386729140A3A899A8B39B046403D5B7@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: AcGKDW+lXpdYqqBBTCq4E6StC00VywAKXeEw X-Mimeole: Produced By Microsoft Exchange V6.0.5762.3 From: "Michel Py" content-class: urn:content-classes:message To: "Brian E Carpenter" , Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA25439 >> Brian Carpenter wrote: >> 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. Agree. The ++ text above could, IMHO, go directly into the requirements draft. Michel. From owner-multi6@ops.ietf.org Fri Dec 21 11:03:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25571 for ; Fri, 21 Dec 2001 11:03:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16HS85-000Hi7-00 for multi6-data@psg.com; Fri, 21 Dec 2001 08:02: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 16HS84-000Hi1-00 for multi6@ops.ietf.org; Fri, 21 Dec 2001 08:02:36 -0800 Subject: RE: Reqt. 3.1.1 [was Re: (multi6) requirements draft comments] Date: Fri, 21 Dec 2001 08:02:35 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405DE0E@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: Reqt. 3.1.1 [was Re: (multi6) requirements draft comments] Thread-Index: AcGKDQwKpmtUkOQ8QdO2LA/OTYZLnAAJmHuw X-Mimeole: Produced By Microsoft Exchange V6.0.5762.3 From: "Michel Py" content-class: urn:content-classes:message To: "Brian E Carpenter" , Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA25571 Brian, >> Brian Carpenter wrote: >> The reason I've railed against Tony's PI proposal is because I >> have serious doubts whether market forces will lead to the >> adoption of metro (or metro-like) addressing and the consequent >> creation of ISP-neutral metro exchanges. I don't see why ISP-neutral metro exchanges would be needed. What I find in Tony's draft is an adressing scheme. What you wrote above leads me to think that you envision this geo addressing as being the only address being used. It does not need to. If sites use their PA address in combination with Tony's PI address, there is no need for local exchanges. >> However, returning to our topic, that would make the metro >> exchanges key failure points in the multihoming system. >> That breaks requirement 3.1.1 in the draft. Do we want to >> insist that the solution MUST accommodate failure of metro >> exchanges? Again, metro exchanges are not necessarily needed. Going back to the problem at hand, what we are bumping into is route aggregation. Let's take the following example: - A site is connected trough multiple transit providers. That site advertises its PI prefix to all its transit providers and each PA prefix only to the provider it belongs to. - The transport of the actual traffic will use MHTP as described in http://search.ietf.org/internet-drafts/draft-py-multi6-mhtp-01.txt (Although the draft describes centrally allocated PI addresses, it could easily use Tony's PI address scheme as well). - Data is actually transported over PA addresses. - The providers do not need to be connected together to a regional exchange. All they need to do is to aggregate the regional routes in order to keep the routing table small. In other words: there is no need for a PI geographical infrastructure. All is needed is PI geographical route aggregation, which is a lot less work for the transit providers. I would support working on Tony's draft when we actually can make proposals working group documents. I agree that the creation of ISP-neutral metro exchanges would probably not happen, but since they are not needed I do see a lot of value in geo addressing. Michel. From owner-multi6@ops.ietf.org Fri Dec 21 11:20:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25857 for ; Fri, 21 Dec 2001 11:20:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16HSP1-000IE8-00 for multi6-data@psg.com; Fri, 21 Dec 2001 08:20:07 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16HSP1-000IE2-00 for multi6@ops.ietf.org; Fri, 21 Dec 2001 08:20:07 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16HSP1-00077D-00 for multi6@ops.ietf.org; Fri, 21 Dec 2001 08:20:07 -0800 Message-ID: <20011221111849.A10756@partan.com> References: <200112202034.PAA08934@ginger.lcs.mit.edu> <3C231143.2E04812C@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <3C231143.2E04812C@hursley.ibm.com>; from brian@hursley.ibm.com on Fri, Dec 21, 2001 at 11:38:59AM +0100 Date: Fri, 21 Dec 2001 11:18:49 -0500 From: Andrew Partan To: Brian E Carpenter Cc: multi6@ops.ietf.org Subject: Re: Missing DNS reqt? [was Re: (multi6) requirements draft comments] Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, Dec 21, 2001 at 11:38:59AM +0100, Brian E Carpenter wrote: > ..which then have to be reflected globally in the DNS before they can be used. > This seems to be a real difficulty in automated address assignments. Not if you seperate EIDs from the routing goop. [Which then leads to the question of how you get from an EID to the routing goop.] > 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. Note that a solution could not effect the DNS at all. I.e.: I could see something that has the EID/routing-goop split and a different (non-DNS) solution of how you get from EIDs to the routing-goop. The DNS would only deal with EIDs. --asp From owner-multi6@ops.ietf.org Fri Dec 21 11:22:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25882 for ; Fri, 21 Dec 2001 11:22:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16HSQn-000IGR-00 for multi6-data@psg.com; Fri, 21 Dec 2001 08:21:57 -0800 Received: from tower.partan.com ([198.6.255.248]) by psg.com with esmtp (Exim 3.33 #1) id 16HSQm-000IGL-00 for multi6@ops.ietf.org; Fri, 21 Dec 2001 08:21:56 -0800 Received: (from asp@localhost) by tower.partan.com (8.9.3/8.9.3) id LAA10837; Fri, 21 Dec 2001 11:21:50 -0500 (EST) Date: Fri, 21 Dec 2001 11:21:49 -0500 From: Andrew Partan To: Michel Py Cc: multi6@ops.ietf.org Subject: Re: Reqt. 3.1.1 [was Re: (multi6) requirements draft comments] Message-ID: <20011221112149.B10756@partan.com> References: <2B81403386729140A3A899A8B39B046405DE0E@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <2B81403386729140A3A899A8B39B046405DE0E@server2000.arneill-py.sacramento.ca.us>; from michel@arneill-py.sacramento.ca.us on Fri, Dec 21, 2001 at 08:02:35AM -0800 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, Dec 21, 2001 at 08:02:35AM -0800, Michel Py wrote: > - The providers do not need to be connected together to a regional > exchange. All they need to do is to aggregate the regional routes > in order to keep the routing table small. Warning - anything that would require me as an ISP to announce an aggregate which contains people that are not my customers will not fly. I.e.: I want to be paid by at least one end of every end-to-end connection... --asp From owner-multi6@ops.ietf.org Fri Dec 21 11:23:50 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25922 for ; Fri, 21 Dec 2001 11:23:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16HSSP-000IIl-00 for multi6-data@psg.com; Fri, 21 Dec 2001 08:23:37 -0800 Received: from tower.partan.com ([198.6.255.248]) by psg.com with esmtp (Exim 3.33 #1) id 16HSSO-000IIb-00 for multi6@ops.ietf.org; Fri, 21 Dec 2001 08:23:36 -0800 Received: (from asp@localhost) by tower.partan.com (8.9.3/8.9.3) id LAA10869; Fri, 21 Dec 2001 11:23:30 -0500 (EST) Date: Fri, 21 Dec 2001 11:23:30 -0500 From: Andrew Partan To: Brian E Carpenter Cc: multi6@ops.ietf.org Subject: Re: Reqt. 3.1.1 [was Re: (multi6) requirements draft comments] Message-ID: <20011221112330.C10756@partan.com> References: <3C230F1D.C185ECB1@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3C230F1D.C185ECB1@hursley.ibm.com>; from brian@hursley.ibm.com on Fri, Dec 21, 2001 at 11:29:49AM +0100 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, Dec 21, 2001 at 11:29:49AM +0100, Brian E Carpenter wrote: > However, returning to our topic, that would make the metro exchanges > key failure points in the multihoming system. That breaks > requirement 3.1.1 in the draft. Do we want to insist that the > solution MUST accommodate failure of metro exchanges? We should insist that the solution MUST accommodate the failure of any single point. --asp From owner-multi6@ops.ietf.org Fri Dec 21 11:53:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26350 for ; Fri, 21 Dec 2001 11:53:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16HSsy-000Iut-00 for multi6-data@psg.com; Fri, 21 Dec 2001 08:51:04 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.33 #1) id 16HSsx-000Iun-00 for multi6@ops.ietf.org; Fri, 21 Dec 2001 08:51:03 -0800 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id LAA10916; Fri, 21 Dec 2001 11:51:01 -0500 Date: Fri, 21 Dec 2001 11:51:01 -0500 From: "J. Noel Chiappa" Message-Id: <200112211651.LAA10916@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: Missing DNS reqt? [was Re: (multi6) requirements draft comments] Cc: jnc@ginger.lcs.mit.edu Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Andrew Partan > Not if you seperate EIDs from the routing goop. [Which then leads to > the question of how you get from an EID to the routing goop.] In engineering terms, I've always felt that a separate mapping mechanism was not necessarily a good idea. While it might make sense architecturally to have separate namespaces for "endpoint identity" and "location", to allow the binding between the two to change, when it came to the actual engineering, in most cases one might find both out in a single packet cycle. In other words, a single DNS transaction might return both the "endpoint identity" and current address. I don't have my feet completely in concrete on this, since I don't think preventing extra packet exchanges is something we have to do at absolutely any cost. (The number of packets needed to load the average web-page laden with zillions of tiny images is pretty amazing, but I don't hear agonized moaning about it all over.) If there's a good reason to pay the cost of an extra packet exchange on a normal connection setup, then OK - but let's do it after careful analysis indicates it's worth it, not just off the top of our heads. (This is all separate from the issue of *whether* one would even want to be able to look in a directory, based on an endpoint name, and find the location(s) of that endpoint. One might use such a capability for error recovery, fault analysis, etc, etc. Most people, when asked this, say "Of course we want to be able to do that", but I'm frankly of two minds about it. The question is whether the expense of maintaining that directory - and it will be considerable - is worth it.) > I could see something that has the EID/routing-goop split By "routing-goop", do you mean exactly the concept in GSE, or are you speaking of a more generic "routing-name"? > and a different (non-DNS) solution of how you get from EIDs to the > routing-goop. The DNS would only deal with EIDs. Why? What's the benefit? Do you have some design in mind that would have substantially lower deployment (i.e. amount of code) or operational (i.e. amount of packets/data) costs, or something? I understand that dynamic updating might be an issue, but that's going to be a problem no matter what system you keep the mapping in. I also understand that DNS has problems, and maybe we really want son-of-DNS. But still, why keep the two mappings in separate databases? What's the benefit, when you look at the entire system? Noel From owner-multi6@ops.ietf.org Fri Dec 21 12:53:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27828 for ; Fri, 21 Dec 2001 12:53:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16HTq6-000K1Q-00 for multi6-data@psg.com; Fri, 21 Dec 2001 09:52:10 -0800 Received: from evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net ([4.60.69.141] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.33 #1) id 16HTq5-000K1I-00 for multi6@ops.ietf.org; Fri, 21 Dec 2001 09:52:09 -0800 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Fri, 21 Dec 2001 09:52:03 -0800 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 30477F95566D454C85064799E5B14471 for plus 1 more; Fri, 21 Dec 2001 09:52:02 -0800 From: "Tony Hain" To: "Andrew Partan" Cc: Subject: RE: (multi6) requirements draft comments Date: Fri, 21 Dec 2001 09:46:58 -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) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <20011221003647.B14280@partan.com> X-SLUIDL: 1C4FA62F-B9C94F6A-A2E52D86-9A203256 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Andrew Partan wrote: > On Thu, Dec 20, 2001 at 01:44:45PM -0800, Tony Hain wrote: > > If you fold the above complexity into your graph along with > the other > > ~12000 ASs that are prefix origins today, and managing the > > topology-names becomes an administrative burden as topology is > > constantly shifting. > > No, not if the system does the work for you. Managing the topology > abstractions is something the system should do, not people. > Reality says that operations people really like to believe they know how the routers are configured. To make the system Noel is describing work, the entire system would have to be self configuring, else everytime a customer connected to another provider each existing provider would have to reconfigure their interface to that customer. > > > the users have to renumber when they change providers, and > > > > Actually they have to renumber everytime their neighbors change > > providers as well, because the entire graph changes around them. > > No, only if they change their attachment point. If your neighor > changes his attachment point, he renumbers, not you. If he changes the entire graph so that it does not fit neatly in the aggrigate, then everyone who is disrupted in the more granular space will have to readdress. Tony From owner-multi6@ops.ietf.org Fri Dec 21 13:16:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28448 for ; Fri, 21 Dec 2001 13:16:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16HUC4-000KQT-00 for multi6-data@psg.com; Fri, 21 Dec 2001 10:14:52 -0800 Received: from tower.partan.com ([198.6.255.248]) by psg.com with esmtp (Exim 3.33 #1) id 16HUC1-000KPw-00 for multi6@ops.ietf.org; Fri, 21 Dec 2001 10:14:51 -0800 Received: (from asp@localhost) by tower.partan.com (8.9.3/8.9.3) id NAA20654; Fri, 21 Dec 2001 13:14:46 -0500 (EST) Date: Fri, 21 Dec 2001 13:14:46 -0500 From: Andrew Partan To: Tony Hain Cc: multi6@ops.ietf.org Subject: Re: (multi6) requirements draft comments Message-ID: <20011221131446.A20518@partan.com> References: <20011221003647.B14280@partan.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from alh-ietf@tndh.net on Fri, Dec 21, 2001 at 09:46:58AM -0800 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, Dec 21, 2001 at 09:46:58AM -0800, Tony Hain wrote: > > No, not if the system does the work for you. Managing the topology > > abstractions is something the system should do, not people. > > > Reality says that operations people really like to believe they know how > the routers are configured. No, we don't know that 100% even today. While I may know what neighbors I have configured on my routers today, I have no idea what routes they are actually sending me right now. [For some neighbors, I may have a list of permissible routes they could send me, but I have no idea what they are actually sending w/o going & looking.] For an IGP, I may only configure what interface to run over - and let the system handle the neighbor discovery. I let the routing system handle the details how to get from A to B after I've set up the gross overall structure. I can do analysis of how the system is supposed to work and what changes in face of updates, and I can put some contraints on the system, and adjust knobs here & there to push it more towards one state or another, but to know what the system is actually doing at any point in time, I'm going to have to go look. If we are going to scale, the system has got to be better at self organizing. Yes there have to be contraints in there (aka 'knobs'), but the system is going to have to take on more of the work. When a new system rolls out, people are going to be doing a lot of looking at it, and set it up with all of the knobs turned way down, and do a lot of making sure that its doing the right thing. [Been there done that with EGP/BGP switch, ospf/isis changeovers, MPLS deployment, others.] But as time goes on and systems (and s/w) proves itself out, the knobs are loosened and you let the system do what it is supposed to. > > > > the users have to renumber when they change providers, and > > > > > > Actually they have to renumber everytime their neighbors change > > > providers as well, because the entire graph changes around them. > > > > No, only if they change their attachment point. If your neighor > > changes his attachment point, he renumbers, not you. > > If he changes the entire graph so that it does not fit neatly in the > aggrigate, then everyone who is disrupted in the more granular space > will have to readdress. If you move, you have to change your info, but no one else does. --asp From owner-multi6@ops.ietf.org Fri Dec 21 13:17:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28468 for ; Fri, 21 Dec 2001 13:17:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16HUEQ-000KSr-00 for multi6-data@psg.com; Fri, 21 Dec 2001 10:17:18 -0800 Received: from evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net ([4.60.69.141] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.33 #1) id 16HUEP-000KSk-00 for multi6@ops.ietf.org; Fri, 21 Dec 2001 10:17:17 -0800 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Fri, 21 Dec 2001 10:17:15 -0800 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 23A84B1B58084449BEBAEDA23BF9DE2E for ; Fri, 21 Dec 2001 10:17:15 -0800 From: "Tony Hain" To: Subject: RE: Reqt. 3.1.1 [was Re: (multi6) requirements draft comments] Date: Fri, 21 Dec 2001 10:12:11 -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) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3C230F1D.C185ECB1@hursley.ibm.com> X-SLUIDL: 7A076044-E46645B0-B924C114-1BBA146A Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > OK, we don't discuss business models in the IETF, but this is the key > issue in moving to any kind of *fixed* address alocation > other than ISP > based PA. I agree we are not in the business of proscribing any specific business model, but we can't define mechanisms that are useful without some context of the models they might be used in. I do believe it is within our realm to describe a tool and a potential set of business models that might apply. > The reason I've railed against Tony's PI proposal is because I have > serious doubts whether market forces will lead to the adoption > of metro (or metro-like) addressing and the consequent creation > of ISP-neutral metro exchanges. In the abstract I would agree, but in reality the market has already created the ISP-neutral exchanges in most of the significant metro areas. What they are missing is an addressing plan that would leverage those. > But in any case, it's something > totally outside the IETF's control. It's also completely compatible > with PA addresses, simple by giving PA blocks to the metro exchanges > if and when they appear. All we can do is write something like a BCP, and let the market decide if that is viable. As far as the use of PA blocks vs. the PI ones I proposed, I really don't think it makes too much difference, the architectural point is to isolate the end customers from the set of transit service providers they may subscribe to. > However, returning to our topic, that would make the metro exchanges > key failure points in the multihoming system. That breaks > requirement 3.1.1 in the draft. Do we want to insist that the > solution MUST accommodate failure of metro exchanges? Yes there should be no single points of failure. The description of a distributed exchange in my current draft is admittedly a hand-wave, and likely inadaquate, but I agree we need to avoid this problem. Tony From owner-multi6@ops.ietf.org Fri Dec 21 13:23:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28664 for ; Fri, 21 Dec 2001 13:23:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16HUKQ-000Ka7-00 for multi6-data@psg.com; Fri, 21 Dec 2001 10:23:30 -0800 Received: from evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net ([4.60.69.141] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.33 #1) id 16HUKP-000Ka0-00 for multi6@ops.ietf.org; Fri, 21 Dec 2001 10:23:29 -0800 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Fri, 21 Dec 2001 10:23:27 -0800 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 57F4633998144992BE72EB9311CE6C4D for ; Fri, 21 Dec 2001 10:23:27 -0800 From: "Tony Hain" To: Subject: RE: Reqt. 3.1.1 [was Re: (multi6) requirements draft comments] Date: Fri, 21 Dec 2001 10:18:24 -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) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <20011221112149.B10756@partan.com> X-SLUIDL: 461E2770-C41846B5-9D5A49FA-8D19AC56 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Andrew Partan wrote: > Warning - anything that would require me as an ISP to announce an > aggregate which contains people that are not my customers will not > fly. I.e.: I want to be paid by at least one end of every end-to-end > connection... As does everyone else. If this is going to fly, the ISP customer will likely become the exchange point, which in turn gets funded by the end customer. Organizations that insist on direct-customer-touch will have to weigh that against the cost of occasional undesired traffic. > We should insist that the solution MUST accommodate the failure of > any single point. Absolutely, if we don't we will be taking a step backward. Tony From owner-multi6@ops.ietf.org Fri Dec 21 13:30:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28816 for ; Fri, 21 Dec 2001 13:30:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16HUQZ-000KjE-00 for multi6-data@psg.com; Fri, 21 Dec 2001 10:29:51 -0800 Received: from evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net ([4.60.69.141] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.33 #1) id 16HUQY-000Kj0-00 for multi6@ops.ietf.org; Fri, 21 Dec 2001 10:29:50 -0800 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Fri, 21 Dec 2001 10:29:48 -0800 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 8FE9E0A995254A078C11C6EE12DE9E3D for ; Fri, 21 Dec 2001 10:29:48 -0800 From: "Tony Hain" To: Subject: RE: (multi6) requirements draft comments Date: Fri, 21 Dec 2001 10:24:44 -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) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <20011221131446.A20518@partan.com> X-SLUIDL: CF598E33-0D3E4F43-AD2F1458-C391B3FD Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Andrew Partan wrote: > > > > > Reality says that operations people really like to believe > they know how > > the routers are configured. > > No, we don't know that 100% even today. While I may know what > neighbors I have configured on my routers today, I have no idea > what routes they are actually sending me right now. [For some > neighbors, I may have a list of permissible routes they could send > me, but I have no idea what they are actually sending w/o going & > looking.] For an IGP, I may only configure what interface to run > over - and let the system handle the neighbor discovery. > Actually you made my point better than I did. Within the realm of a trust boundary (where you would typically run an IGP) you are willing to automate, but at the edge of that bounday, you know who is at the other end (specifically configured) and may apply a sanity check against what may come in from there. If we follow Noel's path, you either couldn't know what address the neighbor was using and would have to autoconfigure, or you have a very high cost process to manually update everytime a customer connected to a different provider. Neither of these fit in a typical provider/customer relationship. > I let the routing system handle the details how to get from A to > B after I've set up the gross overall structure. > > I can do analysis of how the system is supposed to work and what > changes in face of updates, and I can put some contraints on the > system, and adjust knobs here & there to push it more towards one > state or another, but to know what the system is actually doing at > any point in time, I'm going to have to go look. > > If we are going to scale, the system has got to be better at self > organizing. Yes there have to be contraints in there (aka 'knobs'), > but the system is going to have to take on more of the work. > > > When a new system rolls out, people are going to be doing a lot of > looking at it, and set it up with all of the knobs turned way down, > and do a lot of making sure that its doing the right thing. [Been > there done that with EGP/BGP switch, ospf/isis changeovers, MPLS > deployment, others.] But as time goes on and systems (and s/w) > proves itself out, the knobs are loosened and you let the system > do what it is supposed to. This is easy to say, but since the automation is crossing a trust boundary it is much harder to sell. Tony From owner-multi6@ops.ietf.org Fri Dec 21 13:41:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28978 for ; Fri, 21 Dec 2001 13:41:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16HUb3-000KxA-00 for multi6-data@psg.com; Fri, 21 Dec 2001 10:40:41 -0800 Received: from evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net ([4.60.69.141] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.33 #1) id 16HUb2-000Kx2-00 for multi6@ops.ietf.org; Fri, 21 Dec 2001 10:40:40 -0800 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Fri, 21 Dec 2001 10:40:25 -0800 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 6F4BF3F2C0EB4C1F88F34012812D27A5 for plus 2 more; Fri, 21 Dec 2001 10:40:24 -0800 From: "Tony Hain" To: "Andrew Partan" , "Brian E Carpenter" Cc: Subject: RE: Missing DNS reqt? [was Re: (multi6) requirements draft comments] Date: Fri, 21 Dec 2001 10:35:20 -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) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <20011221111849.A10756@partan.com> X-SLUIDL: 8D29B40D-B1C64942-A7CB679B-C7EE7911 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Andrew Partan wrote: > On Fri, Dec 21, 2001 at 11:38:59AM +0100, Brian E Carpenter wrote: > > ... > > 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. > > Note that a solution could not effect the DNS at all. I.e.: I > could see something that has the EID/routing-goop split and a > different (non-DNS) solution of how you get from EIDs to the > routing-goop. The DNS would only deal with EIDs. I agree with Brian, the requirement must include an analysis. Keep in mind that doesn't mean there will necessarily be any impact, but it must be addressed. J. Noel Chiappa wrote: > I understand that dynamic updating might be an issue, but > that's going to be > a problem no matter what system you keep the mapping in. I > also understand > that DNS has problems, and maybe we really want son-of-DNS. > But still, why > keep the two mappings in separate databases? What's the > benefit, when you > look at the entire system? Actually this gets more to the point that I think Brian was after, the solution must include an analysis of its effects on the entire existing system. This would catch DNS, but also any interaction with the current interdomain routing environment. Tony From owner-multi6@ops.ietf.org Fri Dec 21 22:24:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07825 for ; Fri, 21 Dec 2001 22:24:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16HcjS-0002Gk-00 for multi6-data@psg.com; Fri, 21 Dec 2001 19:21:54 -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 16HcjR-0002Ge-00 for multi6@ops.ietf.org; Fri, 21 Dec 2001 19:21:54 -0800 Subject: RE: Reqt. 3.1.1 [was Re: (multi6) requirements draft comments] Date: Fri, 21 Dec 2001 19:21:45 -0800 Message-ID: <2B81403386729140A3A899A8B39B046403D5B9@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: Reqt. 3.1.1 [was Re: (multi6) requirements draft comments] X-Mimeole: Produced By Microsoft Exchange V6.0.5762.3 Thread-Index: AcGKO7+vXe1xZGqzSX6tGdX5BHhUcwAVts8w content-class: urn:content-classes:message From: "Michel Py" To: "Andrew Partan" 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 WAA07825 Andrew, >> Michel Py wrote: >> - The providers do not need to be connected together to >> a regional exchange. All they need to do is to aggregate >> the regional routes in order to keep the routing table small. > Andrew Partan wrote: > Warning - anything that would require me as an ISP to announce > an aggregate which contains people that are not my customers > will not fly. I.e.: I want to be paid by at least one end of > every end-to-end connection... This becomes a non-issue with the PI traffic being a drop in the PA traffic sea. If we don't send out egress untranslated packets, the only traffic concerned would be topology requests which is likely to be acceptable. Michel. From owner-multi6@ops.ietf.org Fri Dec 21 22:27:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07843 for ; Fri, 21 Dec 2001 22:27:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Hcny-0002J5-00 for multi6-data@psg.com; Fri, 21 Dec 2001 19:26:34 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.33 #1) id 16Hcny-0002Iz-00 for multi6@ops.ietf.org; Fri, 21 Dec 2001 19:26:34 -0800 Subject: RE: Reqt. 3.1.1 [was Re: (multi6) requirements draft comments] Date: Fri, 21 Dec 2001 19:26:33 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405DE11@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: Reqt. 3.1.1 [was Re: (multi6) requirements draft comments] X-Mimeole: Produced By Microsoft Exchange V6.0.5762.3 Thread-Index: AcGKPTbYjILfi1w5QBSc21pisMF1ZgAWsZNg content-class: urn:content-classes:message From: "Michel Py" To: "Andrew Partan" , "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 WAA07843 >> Brian E Carpenter wrote: >> However, returning to our topic, that would make the >> metro exchanges key failure points in the multihoming >> system. That breaks requirement 3.1.1 in the draft. >> Do we want to insist that the solution MUST accommodate >> failure of metro exchanges? > Andrew Partan wrote: > We should insist that the solution MUST accommodate the > failure of any single point. We MUST, and I don't think this is even debatable. Michel. From owner-multi6@ops.ietf.org Fri Dec 21 22:46:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08963 for ; Fri, 21 Dec 2001 22:46:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Hd6W-0002WG-00 for multi6-data@psg.com; Fri, 21 Dec 2001 19:45:44 -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 16Hd6V-0002WA-00 for multi6@ops.ietf.org; Fri, 21 Dec 2001 19:45:43 -0800 Subject: RE: Missing DNS reqt? [was Re: (multi6) requirements draft comments] Date: Fri, 21 Dec 2001 19:45:42 -0800 Message-ID: <2B81403386729140A3A899A8B39B046403D5BB@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] X-Mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Thread-Index: AcGKQbl0sVaG0ssmRk6f6mNi+zBBtAAVveFA From: "Michel Py" To: "J. Noel Chiappa" , Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA08963 J. Noel, > J. Noel Chiappa wrote: > If there's a good reason to pay the cost of an extra > packet exchange on a normal connection setup, then OK > - but let's do it after careful analysis indicates it's > worth it, not just off the top of our heads. These days, one more packet is a drop is the sea. On a typical web page, there are a zillion references to other FQDNs that each require a DNS query and a gazillion 3-pixel wide jpegs that the trained brain of the heavy surfer does not even see that each require establishing and tearing down a TCP connection. My take is: if it's ONE extra packet, no point even discussing it. More than ten packets, let's talk about it. > (This is all separate from the issue of *whether* one would even > want to be able to look in a directory, based on an endpoint name, > and find the location(s) of that endpoint. One might use such a > capability for error recovery, fault analysis, etc, etc. Most > people, when asked this, say "Of course we want to be able to do > that", but I'm frankly of two minds about it. The question is > whether the expense of maintaining that directory - and it > will be considerable - is worth it.) 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. Michel. http://search.ietf.org/internet-drafts/draft-py-multi6-mhtp-01.txt