Received: from cnri by ietf.org id aa16319; 4 Dec 96 21:13 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa27316; 4 Dec 96 21:13 EST Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id LAA05522 for ; Thu, 5 Dec 1996 11:44:16 +1100 Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.7.3/8.7.3) with ESMTP id TAA09177; Wed, 4 Dec 1996 19:42:39 -0500 (EST) Message-Id: <199612050042.TAA09177@brookfield.ans.net> To: Tony Li cc: nanog@merit.edu, cidrd@iepg.org, metro@nlanr.net Reply-To: curtis@ans.net Subject: Re: ISPACs In-reply-to: Your message of "Tue, 26 Nov 1996 12:49:12 PST." <199611262049.MAA05750@chimp.jnx.com> Date: Wed, 04 Dec 1996 19:42:29 -0500 From: Curtis Villamizar In message <199611262049.MAA05750@chimp.jnx.com>, Tony Li writes: > > Folks, > > I'd like to point your attention to the following ID. I would appreciate > any comments. For the lack of a better place, I'd ask that discussion be > on the cidrd mailing list. > > Thanks, > Tony > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Internet Service Provider Address Coalitions (ISPACs) > Author(s) : T. Li > Filename : draft-li-ispac-00.txt > Pages : 5 > Date : 11/25/1996 Tony, I can't see how ISPACs are anything but a NOOP. If members of the ISPAC connect to different providers then aggregation can't be performed. They can get the address space and suballocate /24s to each other but if the /24s can't be aggregated and are unroutable what's the point? If the smaller providers aggregate they have to all buy transit from the same provider or agree to transit each others traffic or build their own backbone as an organization at T3 speed in order to peer with other providers as a single entity. Other than leveraging buying power what purpose does the ISPAC serve? Do we need an RFC for this? IMO ISPACs would be almost a NOOP so the RFC would be a NOOP and we have enough junk RFCs already. None of it isn't true so I certainly won't waste energy fighting this if you want to push it through. Curtis   Received: from cnri by ietf.org id aa16320; 4 Dec 96 21:13 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa27317; 4 Dec 96 21:13 EST Received: from red.jnx.com (red.jnx.com [208.197.169.254]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id MAA07650 for ; Thu, 5 Dec 1996 12:11:56 +1100 Received: from chimp.jnx.com (chimp.jnx.com [208.197.169.246]) by red.jnx.com (8.8.3/8.8.3) with ESMTP id RAA24276; Wed, 4 Dec 1996 17:10:43 -0800 (PST) Received: (from tli@localhost) by chimp.jnx.com (8.7.6/8.7.3) id RAA18589; Wed, 4 Dec 1996 17:10:31 -0800 (PST) Date: Wed, 4 Dec 1996 17:10:31 -0800 (PST) Message-Id: <199612050110.RAA18589@chimp.jnx.com> From: Tony Li To: curtis@ans.net CC: nanog@merit.edu, cidrd@iepg.org, metro@nlanr.net In-reply-to: <199612050042.TAA09177@brookfield.ans.net> (message from Curtis Villamizar on Wed, 04 Dec 1996 19:42:29 -0500) Subject: Re: ISPACs I can't see how ISPACs are anything but a NOOP. If members of the ISPAC connect to different providers then aggregation can't be performed. ? Why not? Yes, they have to provide transit to each other for the full ISPAC prefix.... If the smaller providers aggregate they have to all buy transit from the same provider or agree to transit each others traffic or build their own backbone as an organization at T3 speed in order to peer with other providers as a single entity. Yup. We expect the most common case would be to touch down at a common set of interconnects and then peer with other providers. Yes, there are details and many options to be considered... Other than leveraging buying power what purpose does the ISPAC serve? It allows us to allocate addresses to smaller ISPs (hey ma, I've got a Unix box and three modems, I'm gonna be an ISP and get me a /17 from the NIC!) in a larger block and provide aggregation across all of the ISPs. It allows (some) users to change providers within the ISPAC and not have to renumber. Do we need an RFC for this? IMO ISPACs would be almost a NOOP so the RFC would be a NOOP and we have enough junk RFCs already. None of it isn't true so I certainly won't waste energy fighting this if you want to push it through. Curtis, no one hates stupid wasteful RFCs more than I do. So I'll make you a deal: if we talk this through (and I mean talk - not just an Ohta-style declaration of incompetence, thank you) and folks think that it's pointless, then I'll kill it myself. In return, I ask that you seriously consider all of the angles. Fair 'nuf? Tony   Received: from cnri by ietf.org id aa27741; 5 Dec 96 0:05 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa01206; 5 Dec 96 0:05 EST Received: from smtp2.erols.com (smtp2.erols.com [205.252.116.102]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id NAA13108 for ; Thu, 5 Dec 1996 13:43:56 +1100 Received: from justin.erols.com (justin.erols.com [205.252.116.48]) by smtp2.erols.com (8.7.5/8.7.3) with SMTP id VAA08849 for ; Wed, 4 Dec 1996 21:43:34 -0500 (EST) Message-Id: <3.0b36.32.19961204214814.0134def8@justin.erols.com> X-Sender: justin@justin.erols.com X-Mailer: Windows Eudora Pro Version 3.0b36 (32) Date: Wed, 04 Dec 1996 21:48:14 -0500 To: cidrd@iepg.org From: "Justin W. Newton" Subject: Re: ISPACs Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 05:10 PM 12/4/96 -0800, Tony Li wrote: > > I can't see how ISPACs are anything but a NOOP. If members of the > ISPAC connect to different providers then aggregation can't be > performed. > >? Why not? Yes, they have to provide transit to each other for the full >ISPAC prefix.... And what, in reality, to you believe to be the likelyhood of this happening. Ok, lets look at it this way. I am running MomAndPopsISP. I want PI space, so I join a ISPAC. Ok, now I am /dependant/ upon my direct competitors (other ISPs of the same size, and presumably in the same geographic region in order to make a small internal network for internal transit purposes wotrthwhile). If /any one/ of my competitors is either unethical or incompetent, it affects me and my users. I'm sorry, but I'd rather eat the IPv8 typed on razorblades than do that. It just isn't good business sense from my perspective. I am suddenly dependant on someone who I am /not/ paying, who is likely a direct competitor of mine, and who can likely provide me no garuntee as to the technical ability of their staff. Justin Newton Network Architect Erol's Internet Services   Received: from cnri by ietf.org id aa28659; 5 Dec 96 0:52 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa02071; 5 Dec 96 0:52 EST Received: from alink.net (ns.alink.net [207.135.127.66]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id PAA26832 for ; Thu, 5 Dec 1996 15:41:30 +1100 Received: from quest.pluris.com (avg@quest.pluris.com [207.135.126.68]) by alink.net (8.8.0/8.7.3) with ESMTP id UAA08450 for ; Wed, 4 Dec 1996 20:40:59 -0800 Received: (from avg@localhost) by quest.pluris.com (8.6.9/8.6.9) id UAA00904 for cidrd@iepg.org; Wed, 4 Dec 1996 20:40:03 -0800 Date: Wed, 4 Dec 1996 20:40:03 -0800 From: Vadim Antonov Message-Id: <199612050440.UAA00904@quest.pluris.com> To: cidrd@iepg.org Subject: Re: ISPACs Nice idea, but i do not think it is practical. Too complicated, and the potential yield is small :( I'd rather fought the battle with CSU vendors and router manufacturers to change default timing parameters in CSUs and make static routes persistent by default (and add exponential dampening in line keepalive protocols). Those two simple tricks would reduce flap by 90% by killing its source instead of treating its symptoms. And then, there's always TWD. --vadim   Received: from cnri by ietf.org id aa01299; 5 Dec 96 2:37 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa03430; 5 Dec 96 2:37 EST Received: from red.jnx.com (red.jnx.com [208.197.169.254]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id RAA01605 for ; Thu, 5 Dec 1996 17:49:19 +1100 Received: from chimp.jnx.com (chimp.jnx.com [208.197.169.246]) by red.jnx.com (8.8.3/8.8.3) with ESMTP id WAA08161; Wed, 4 Dec 1996 22:49:02 -0800 (PST) Received: (from tli@localhost) by chimp.jnx.com (8.7.6/8.7.3) id WAA19007; Wed, 4 Dec 1996 22:48:49 -0800 (PST) Date: Wed, 4 Dec 1996 22:48:49 -0800 (PST) Message-Id: <199612050648.WAA19007@chimp.jnx.com> From: Tony Li To: avg@pluris.com CC: cidrd@iepg.org In-reply-to: <199612050440.UAA00904@quest.pluris.com> (message from Vadim Antonov on Wed, 4 Dec 1996 20:40:03 -0800) Subject: Re: ISPACs Nice idea, but i do not think it is practical. Too complicated, and the potential yield is small :( I'd rather fought the battle with CSU vendors and router manufacturers to change default timing parameters in CSUs and make static routes persistent by default (and add exponential dampening in line keepalive protocols). Those two simple tricks would reduce flap by 90% by killing its source instead of treating its symptoms. And then, there's always TWD. And pray tell, how did this diverge to route flap? Tony   Received: from cnri by ietf.org id aa02024; 5 Dec 96 2:53 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa03629; 5 Dec 96 2:53 EST Received: from red.jnx.com (red.jnx.com [208.197.169.254]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id RAA01734 for ; Thu, 5 Dec 1996 17:58:07 +1100 Received: from chimp.jnx.com (chimp.jnx.com [208.197.169.246]) by red.jnx.com (8.8.3/8.8.3) with ESMTP id WAA08540; Wed, 4 Dec 1996 22:57:47 -0800 (PST) Received: (from tli@localhost) by chimp.jnx.com (8.7.6/8.7.3) id WAA19023; Wed, 4 Dec 1996 22:57:34 -0800 (PST) Date: Wed, 4 Dec 1996 22:57:34 -0800 (PST) Message-Id: <199612050657.WAA19023@chimp.jnx.com> From: Tony Li To: justin@erols.com CC: cidrd@iepg.org In-reply-to: <3.0b36.32.19961204214814.0134def8@justin.erols.com> Subject: Re: ISPACs And what, in reality, to you believe to be the likelyhood of this happening. Pretty good, but then again, my opinion and $2.50 will get you a double latte. ;-) Ok, lets look at it this way. I am running MomAndPopsISP. I want PI space, so I join a ISPAC. Bzzt. An ISPAC is _not_ PI space. If that's what you wanted, you came to the wrong place. Ok, now I am /dependant/ upon my direct competitors (other ISPs of the same size, and presumably in the same geographic region in order to make a small internal network for internal transit purposes wotrthwhile). If /any one/ of my competitors is either unethical or incompetent, it affects me and my users. I'm sorry, but I'd rather eat the IPv8 typed on razorblades than do that. It just isn't good business sense from my perspective. Then there's a whole lot of business that goes on today that must not make sense to you. Lots of folks team up together with direct competitors for ad hoc projects. Heard of the Frame Relay Forum? I am suddenly dependant on someone who I am /not/ paying, who is likely a direct competitor of mine, and who can likely provide me no garuntee as to the technical ability of their staff. And they're dependent on you. Can you cooperate? Mebbe you personally can't, but I'd like to think that there are many who could and would if they saw the benefits. Tony   Received: from cnri by ietf.org id aa03466; 5 Dec 96 3:14 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa03983; 5 Dec 96 3:14 EST Received: from hen.nca.or.kr (nca.or.kr [202.30.65.7]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id SAA01984 for ; Thu, 5 Dec 1996 18:10:59 +1100 Received: from silky.nca.or.kr (silky.nca.or.kr [202.30.66.11]) by hen.nca.or.kr (8.6.12h2/8.6.9) with SMTP id QAA25089 for ; Thu, 5 Dec 1996 16:09:10 +0900 Message-ID: <32A6784B.41B9@nic.nca.or.kr> Date: Thu, 05 Dec 1996 16:22:52 +0900 From: Matthew Bae X-Mailer: Mozilla 3.0 (Win95; I) MIME-Version: 1.0 To: cidrd@iepg.org Subject: subscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit subscribe   Received: from cnri by ietf.org id aa06140; 5 Dec 96 3:56 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa04619; 5 Dec 96 3:56 EST Received: from mail2.digital.com (mail2.digital.com [204.123.2.56]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id TAA02879 for ; Thu, 5 Dec 1996 19:05:22 +1100 Received: from pobox1.pa.dec.com by mail2.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA10423; Wed, 4 Dec 1996 23:58:55 -0800 Received: by pobox1.pa.dec.com; id AA28748; Wed, 4 Dec 96 23:57:56 -0800 Received: from localhost by nsl-too.pa.dec.com; (5.65v3.2/1.1.8.2/13Jul94-0558PM) id AA10466; Wed, 4 Dec 1996 23:57:44 -0800 Message-Id: <9612050757.AA10466@nsl-too.pa.dec.com> To: "Justin W. Newton" Cc: cidrd@iepg.org, stuart@pa.dec.com Subject: Re: ISPACs In-Reply-To: Your message of Wed, 04 Dec 96 21:48:14 -0500. <3.0b36.32.19961204214814.0134def8@justin.erols.com> Date: Wed, 04 Dec 96 23:57:44 -0800 From: Stephen Stuart X-Mts: smtp Based on Justin's comment below: > At 05:10 PM 12/4/96 -0800, Tony Li wrote: > > > > I can't see how ISPACs are anything but a NOOP. If members of the > > ISPAC connect to different providers then aggregation can't be > > performed. > > > >? Why not? Yes, they have to provide transit to each other for the full > >ISPAC prefix.... > > [...] I am suddenly dependant on someone who > I am /not/ paying, who is likely a direct competitor of mine, and who can > likely provide me no garuntee as to the technical ability of their staff. ISPACs are, then, a form of fate-sharing? In terms of promoting inter-provider cooperation, ISPACs might be just the ticket (no pun intended), by demanding cooperation within small groups whose fates are entwined. Or would that be unworkable in the face of the lawyering required to implement it? Stephen - ----- Stephen Stuart stuart@pa.dec.com Network Systems Laboratory Digital Equipment Corporation   Received: from cnri by ietf.org id aa06221; 5 Dec 96 4:00 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa04687; 5 Dec 96 4:00 EST Received: from biff.ibm.net.il (biff.ibm.net.il [192.115.72.164]) by nico.aarnet.edu.au (8.6.10/8.6.10) with ESMTP id SAA02683 for ; Thu, 5 Dec 1996 18:51:07 +1100 Received: from rex.ibm.net.il (root@rex.ibm.net.il [192.115.72.138]) by biff.ibm.net.il (8.8.3/8.8.2) with ESMTP id JAA18340 for ; Thu, 5 Dec 1996 09:43:38 +0200 Received: from rex.ibm.net.il (hank@rex.ibm.net.il [192.115.72.138]) by rex.ibm.net.il (8.8.2/8.8.2) with SMTP id JAA39762 for ; Thu, 5 Dec 1996 09:51:01 +0200 Date: Thu, 5 Dec 1996 09:51:01 +0200 (IST) From: Hank Nussbacher To: cidrd@iepg.org Subject: classless inaddr Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Will any progress be made on this doc? I see no discussion here on the matter. Hank Nussbacher   Received: from cnri by ietf.org id aa09099; 5 Dec 96 5:32 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa05965; 5 Dec 96 5:32 EST Received: from alink.net (ns.alink.net [207.135.127.66]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id UAA04163 for ; Thu, 5 Dec 1996 20:35:00 +1100 Received: from quest.pluris.com (avg@quest.pluris.com [207.135.126.68]) by alink.net (8.8.0/8.7.3) with ESMTP id BAA12978; Thu, 5 Dec 1996 01:34:47 -0800 Received: (from avg@localhost) by quest.pluris.com (8.6.9/8.6.9) id BAA00983; Thu, 5 Dec 1996 01:33:53 -0800 Date: Thu, 5 Dec 1996 01:33:53 -0800 From: Vadim Antonov Message-Id: <199612050933.BAA00983@quest.pluris.com> To: avg@pluris.com, tli@jnx.com Subject: Re: ISPACs Cc: cidrd@iepg.org Memory is cheap. There's noting bad about a routing table with a million entries (it's only six to eight Mb, with a sane data structure) if there's little flap. So the main reason to reduce the routing table size is to reduce flap. What i am saying is that a lot more significant effect can be achieved with a way simpler means. --vadim >And pray tell, how did this diverge to route flap? >Tony   Received: from cnri by ietf.org id aa18523; 5 Dec 96 9:06 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa09583; 5 Dec 96 9:06 EST Received: from roam.psg.com ([146.83.16.142]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id XAA07045 for ; Thu, 5 Dec 1996 23:59:41 +1100 Received: by roam.psg.com id m0vVdNl-000IVSC; Thu, 5 Dec 96 04:58 PST (Smail3.1.29.1#2) Message-Id: Date: Thu, 5 Dec 96 04:58 PST From: Randy Bush To: Hank Nussbacher Cc: cidrd@iepg.org Subject: Re: classless inaddr References: > Will any progress be made on this doc? I see no discussion here > on the matter. it has been moved back to dnssec and put to the IESG for immediate push to BCP. randy   Received: from cnri by ietf.org id aa26592; 5 Dec 96 11:25 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa13748; 5 Dec 96 11:25 EST Received: from roam.psg.com ([146.83.16.142]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id CAA11335 for ; Fri, 6 Dec 1996 02:29:42 +1100 Received: by roam.psg.com id m0vVfjC-000IVRC; Thu, 5 Dec 96 07:28 PST (Smail3.1.29.1#2) Message-Id: Date: Thu, 5 Dec 96 07:28 PST From: Randy Bush To: Robert Elz Cc: cidrd@iepg.org Subject: Re: classless inaddr References: <11394.849796323@munnari.OZ.AU> >> it has been moved back to dnssec > Randy did mean dnsind... As usual, kre is correct. My apologies. Thanks kre. randy   Received: from cnri by ietf.org id aa27121; 5 Dec 96 11:36 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa14255; 5 Dec 96 11:36 EST Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id BAA10307 for ; Fri, 6 Dec 1996 01:32:20 +1100 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id OA07648; Fri, 6 Dec 1996 01:32:05 +1100 (from kre@munnari.OZ.AU) To: Randy Bush Cc: cidrd@iepg.org Subject: Re: classless inaddr In-Reply-To: Your message of "Thu, 05 Dec 1996 04:58:00 PST." Date: Fri, 06 Dec 1996 01:32:03 +1100 Message-Id: <11394.849796323@munnari.OZ.AU> From: Robert Elz Date: Thu, 5 Dec 96 04:58 PST From: randy@psg.com (Randy Bush) Message-ID: it has been moved back to dnssec Randy did mean dnsind... kre   Received: from cnri by ietf.org id aa27572; 5 Dec 96 11:38 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa14337; 5 Dec 96 11:38 EST Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id BAA10237 for ; Fri, 6 Dec 1996 01:29:30 +1100 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id OA10050; Fri, 6 Dec 1996 01:29:13 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: cidrd@iepg.org Subject: classless in-addr.arpa delegation Date: Fri, 06 Dec 1996 01:29:11 +1100 Message-Id: <11388.849796151@munnari.OZ.AU> Sender: kre@munnari.oz.au It has been pointed out that this WG should be told that the draft draft-ietf-cidrd-classless-inaddr-02.txt.Z has been renamed draft-ietf-dnsind-classless-inaddr-00.txt.Z and will now be considered (finished) in dnsind instead of cidrd. (dnsind's mailing list is namedroppers@internic.net) I am doing this for no particularly better reason than that I know it happened (and suggested it, as it seemed to be getting precisely nowhere here), and because no-one else has done so. kre   Received: from cnri by ietf.org id aa28333; 5 Dec 96 11:52 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa14719; 5 Dec 96 11:52 EST Received: from metro.isi.edu (metro.isi.edu [38.245.76.2]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id CAA11728 for ; Fri, 6 Dec 1996 02:44:39 +1100 Received: from metro.isi.edu by metro.isi.edu (5.65c/5.61+local-23) id ; Thu, 5 Dec 1996 10:44:22 -0500 Message-Id: <199612051544.AA11124@metro.isi.edu> To: Tony Li Cc: justin@erols.com, cidrd@iepg.org Subject: Re: ISPACs In-Reply-To: Your message of "Wed, 04 Dec 1996 22:57:34 PST." <199612050657.WAA19023@chimp.jnx.com> X-Phone: +1 703 812 3704 Date: Thu, 05 Dec 1996 10:44:22 EST From: "John W. Stewart III" > Ok, now I am /dependant/ upon my direct > competitors (other ISPs of the same size, and presumably in the same > geographic region in order to make a small internal network for internal > transit purposes wotrthwhile). If /any one/ of my competitors is either > unethical or incompetent, it affects me and my users. I'm sorry, but I'd > rather eat the IPv8 typed on razorblades than do that. It just isn't > good business sense from my perspective. > > Then there's a whole lot of business that goes on today that must not make > sense to you. Lots of folks team up together with direct competitors for > ad hoc projects. Heard of the Frame Relay Forum? > > I am suddenly dependant on someone who > I am /not/ paying, who is likely a direct competitor of mine, and who can > likely provide me no garuntee as to the technical ability of their staff. > > And they're dependent on you. Can you cooperate? Mebbe you personally > can't, but I'd like to think that there are many who could and would if > they saw the benefits. i'm not sure what i think of ISPACs yet, but relative to the above exchange, the internet of *today* already has inter- dependence between parties that don't pay each other. imagine that i connect to ISP1, ISP1 and ISP2 peer, and My-Favorite- Web-Site connects to ISP2. now imagine that ISP2 does something to permanently cut itself off from ISP1. even though it's not ISP1's fault, i would consider changing providers (i.e., stop paying ISP1) i'll grant that today's inter-dependence doesn't involve shared address allocations, but the point is that providers' businesses already depend to some degree on other providers working, so it's not a *fundamental* change .. just a new detail /jws   Received: from cnri by ietf.org id aa09028; 5 Dec 96 14:49 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa19962; 5 Dec 96 14:49 EST Received: from smtp1.erols.com (smtp1.erols.com [205.252.116.101]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id FAA14740 for ; Fri, 6 Dec 1996 05:27:27 +1100 Received: from justin.erols.com (justin.erols.com [205.252.116.48]) by smtp1.erols.com (8.7.5/8.7.3) with SMTP id NAA24720 for ; Thu, 5 Dec 1996 13:27:11 -0500 (EST) Message-Id: <3.0b36.32.19961205133200.008ff754@justin.erols.com> X-Sender: justin@justin.erols.com X-Mailer: Windows Eudora Pro Version 3.0b36 (32) Date: Thu, 05 Dec 1996 13:32:00 -0500 To: cidrd@iepg.org From: "Justin W. Newton" Subject: Re: ISPACs Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 10:44 AM 12/5/96 EST, John W. Stewart III wrote: Tony says: > > And they're dependent on you. Can you cooperate? Mebbe you personally > > can't, but I'd like to think that there are many who could and would if > > they saw the benefits. I am very capable of cooperation if there is a large benefit, what I see in your proposal, however, is a large risk with little benefit. Maybe I am missing something, but what do I, as a small ISP gain by doing this? My risks are farily apparent (at least some of them are). 1) I am dependant on competitors of mine of whom I may be somewhat unsure as to their technical ability, and there is always the possibility that they will act in an unscrupulous manner and /intentionally/ hose over my announcements. The only defense I have against this is strong legal reprecussions for failure to properly handle routing announcements and sharing of traffic. 2) If those strong legal terms /are/ in the contracts, I am suddenly open to lawsuit from my competitors (one may substitute the word competitor with peer if they so choose). If a customer feels that I am providing inadequate service they will likely choose to go to another ISP, which is bad. If a competitor feels that I am damaging their business through a technical relationship that we have they are likely to take me to court. Guess how expensive that can be? > >i'm not sure what i think of ISPACs yet, but relative to the >above exchange, the internet of *today* already has inter- >dependence between parties that don't pay each other. imagine >that i connect to ISP1, ISP1 and ISP2 peer, and My-Favorite- >Web-Site connects to ISP2. now imagine that ISP2 does >something to permanently cut itself off from ISP1. even >though it's not ISP1's fault, i would consider changing >providers (i.e., stop paying ISP1) Right, but in this case you lose connectivity to ISP2's customers. In the situation that Tony is describing if one of /our competitors/ decides to screw you, or simply doesn't have the technical ability on staff to make things work, your connectivity to every site on the internet gets screwed up. As an engineer this is something that wouldn't be hard to make go, and if the people who were involved in an ISPAC were of the caliber of skill as the people commenting on this thread I wouldn't hesitate to join one. The problem comes from the fact that there simply aren't many people at small ISP's (the under 10,000 user size), who are of that caliber, and many of the people who are are being recruited constantly by larger companies. Maybe there are people out there who want to put the fate of their company into an unstable situation. I am not one of those people. I spend a large portion of my time attempting to make certain that my network is /not/ fate shared with other people, why would one willingly put themselves in a position where they are sharing their connectivity fate with several companies who's technical ability is an unknown, and who have a direct interest in seeing me fail, and almost no gain by seeing me succeed. > >i'll grant that today's inter-dependence doesn't involve >shared address allocations, but the point is that providers' >businesses already depend to some degree on other providers >working, so it's not a *fundamental* change .. just a new >detail > >/jws > > > Justin Newton Network Architect Erol's Internet Services   Received: from cnri by ietf.org id aa24161; 5 Dec 96 18:15 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa27327; 5 Dec 96 18:15 EST Received: from red.jnx.com (red.jnx.com [208.197.169.254]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id IAA18451 for ; Fri, 6 Dec 1996 08:59:34 +1100 Received: from chimp.jnx.com (chimp.jnx.com [208.197.169.246]) by red.jnx.com (8.8.3/8.8.3) with ESMTP id NAA13143; Thu, 5 Dec 1996 13:59:21 -0800 (PST) Received: (from tli@localhost) by chimp.jnx.com (8.7.6/8.7.3) id NAA20397; Thu, 5 Dec 1996 13:59:06 -0800 (PST) Date: Thu, 5 Dec 1996 13:59:06 -0800 (PST) Message-Id: <199612052159.NAA20397@chimp.jnx.com> From: Tony Li To: justin@erols.com CC: cidrd@iepg.org In-reply-to: <3.0b36.32.19961205133200.008ff754@justin.erols.com> Subject: Re: ISPACs I am very capable of cooperation if there is a large benefit, what I see in your proposal, however, is a large risk with little benefit. Maybe I am missing something, but what do I, as a small ISP gain by doing this? My risks are farily apparent (at least some of them are). So in case it still isn't obvious: you get access to a larger address block, which is aggregated as a group. You're not dependent on address space from an upstream provider. You can provide address space to your customers which decreases their need to renumber (depending on the proliferation of the ISPAC). 1) I am dependant on competitors of mine of whom I may be somewhat unsure as to their technical ability, and there is always the possibility that they will act in an unscrupulous manner and /intentionally/ hose over my announcements. If you're that worried, then you may wish to pursue the common interconnect model rather than the mutual exchange of transit. Depending on exact details, it would mean that you would only have to trust the folks running the interconnect. The only defense I have against this is strong legal reprecussions for failure to properly handle routing announcements and sharing of traffic. Just like today... 2) If those strong legal terms /are/ in the contracts, I am suddenly open to lawsuit from my competitors (one may substitute the word competitor with peer if they so choose). Just like today... but without the contract. If a customer feels that I am providing inadequate service they will likely choose to go to another ISP, which is bad. If a competitor feels that I am damaging their business through a technical relationship that we have they are likely to take me to court. Guess how expensive that can be? So based on this, I assume that you have no contracts or agreements with anyone. Moreover, I have to assume that you're not in the US, where you can be sued for giving someone a cup of coffee. ;-) Tony   Received: from cnri by ietf.org id aa02255; 5 Dec 96 20:07 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa00922; 5 Dec 96 20:07 EST Received: from [203.50.0.66] (gorp.telstra.net [203.50.0.66]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id LAA20969; Fri, 6 Dec 1996 11:09:26 +1100 X-Sender: gih@nico.aarnet.edu.au Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 6 Dec 1996 11:09:44 +1000 To: Hank Nussbacher From: Geoff Huston Subject: Re: classless inaddr Cc: cidrd@iepg.org At 5:51 PM 5/12/96, Hank Nussbacher wrote: >Will any progress be made on this doc? I see no discussion here >on the matter. > >Hank Nussbacher I was under the impression that the draft was suitable for publication as a BCP as was. But its now a DNSIND call I suppose. Geoff   Received: from cnri by ietf.org id aa17918; 5 Dec 96 22:49 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa04409; 5 Dec 96 22:49 EST Received: from smtp1.erols.com (smtp1.erols.com [205.252.116.101]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id MAA23143 for ; Fri, 6 Dec 1996 12:02:55 +1100 Received: from justin.erols.com (justin.erols.com [205.252.116.48]) by smtp1.erols.com (8.7.5/8.7.3) with SMTP id UAA29865; Thu, 5 Dec 1996 20:02:26 -0500 (EST) Message-Id: <3.0b36.32.19961205200720.0139c8d4@justin.erols.com> X-Sender: justin@justin.erols.com X-Mailer: Windows Eudora Pro Version 3.0b36 (32) Date: Thu, 05 Dec 1996 20:07:25 -0500 To: Tony Li From: "Justin W. Newton" Subject: Re: ISPACs Cc: cidrd@iepg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 01:59 PM 12/5/96 -0800, Tony Li wrote: > > I am very capable of cooperation if there is a large benefit, what I see in > your proposal, however, is a large risk with little benefit. Maybe I am > missing something, but what do I, as a small ISP gain by doing this? My > risks are farily apparent (at least some of them are). > >So in case it still isn't obvious: you get access to a larger address >block, which is aggregated as a group. You're not dependent on address >space from an upstream provider. You can provide address space to your >customers which decreases their need to renumber (depending on the >proliferation of the ISPAC). Right, so instead of my customers having to renumber if I want to leave my upstream provider, my customers have to renumber if I want to leave the ISPAC I am in. To use your words, "just like today". > > 1) I am dependant on competitors of mine of whom I may be somewhat unsure > as to their technical ability, and there is always the possibility that > they will act in an unscrupulous manner and /intentionally/ hose over my > announcements. > >If you're that worried, then you may wish to pursue the common interconnect >model rather than the mutual exchange of transit. Depending on exact >details, it would mean that you would only have to trust the folks running >the interconnect. Ok, so am I buying bandwidth from the people who run the interconnect? I see 2 possibilities here, as follows... 1) I am buying bandwidth from the person running an interconnect, in which case they become my provider, "just like today". 2) Other members of the ISPAC's data cross my network to get to the ISPAC interconnect, and my traffic transits their network to get to the interconnect, effectively allowing my competitors to use my potentially better connectivity, and I become dependant on their network to make certain that my users connectivity isn't affected. I believe that I covered the reasons that people may be uncomfortable with that in detail before. > > The only defense I have against this is strong legal > reprecussions for failure to properly handle routing announcements and > sharing of traffic. > >Just like today... Yes, and today I do not enter into agreements with my direct competitors where They have the ability to destroy connectivity for all of my customers to the entire internet, unless I am buying transi from them, and even then it is a deal between my comapny and a single company who I selected, not some whacked consortium where I may or may not have say as to who has the ability to affect my traffic. Yes, BGP peers /could/ do the same thing to me, but its a lot easier for me to turn off a peering session than instantaneously renumber my network. > > 2) If those strong legal terms /are/ in the contracts, I am suddenly open > to lawsuit from my competitors (one may substitute the word competitor with > peer if they so choose). > >Just like today... but without the contract. Yes, but such a lawsuit would likely be considered frivolous. Unless I was maliciously attacking my competitor via ping floods or something of the like, it would be quite difficult for them to launch a lawsuit that would be considered other than frivilous in a US court. If, however, their traffic crosses my backbone, its is a lot easier for them to have /real cause/ to be suing me. What happens when they don't feel that I have adequate generator power? What happens when my routers have problems (and this is something that has happened on every complex backbone I have ever seen)? Right now, this only impacts my customers, with whome I have an agreement as to what damages they can collect in such an arrangement. If you (collectively as a group) can come up with a legal agreement which both: 1) Adequately protects me from my competitor trying to screw me over when I join an ISPAC of which they are a member, and 2) Protects me from being sued by my competitor if I am making a good faith effort to deliver their packets, you will have come a long way in making your proposal a reality. Until such a document exists we are wasting our time on this proposal, noone will use it. Tony, why don't you go propose this on inet-access where all of the people who would actually become members of these ISPACs actually are, instead of over here on cidrd where most of the members already receive space directly from the regional registry of their choice? > > If a customer feels that I am providing > inadequate service they will likely choose to go to another ISP, which is > bad. If a competitor feels that I am damaging their business through a > technical relationship that we have they are likely to take me to court. > Guess how expensive that can be? > >So based on this, I assume that you have no contracts or agreements with >anyone. Moreover, I have to assume that you're not in the US, where you >can be sued for giving someone a cup of coffee. ;-) I have contracts and agreements with a lot of people, my upstream provider, my bgp peers, my customers, etc etc. In the case of my upstream, they lose significant revenue if I leave, in the case of my BGP peers, I can turn off the peering sessions very quickly which limits the amoiunt of damage they can do to me. And yes, I can get sued over a cup of coffee, but this does not mean that I wish to make my exposure as great as possible, quite the contrary, I try to limit my legal liability as much as possible. Justin Newton Network Architect Erol's Internet Services   Received: from cnri by ietf.org id aa18166; 5 Dec 96 22:53 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa04593; 5 Dec 96 22:53 EST Received: from red.jnx.com (red.jnx.com [208.197.169.254]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id MAA23909 for ; Fri, 6 Dec 1996 12:30:27 +1100 Received: from chimp.jnx.com (chimp.jnx.com [208.197.169.246]) by red.jnx.com (8.8.3/8.8.3) with ESMTP id RAA22439; Thu, 5 Dec 1996 17:30:24 -0800 (PST) Received: (from tli@localhost) by chimp.jnx.com (8.7.6/8.7.3) id RAA21165; Thu, 5 Dec 1996 17:30:11 -0800 (PST) Date: Thu, 5 Dec 1996 17:30:11 -0800 (PST) Message-Id: <199612060130.RAA21165@chimp.jnx.com> From: Tony Li To: justin@erols.com CC: cidrd@iepg.org In-reply-to: <3.0b36.32.19961205200720.0139c8d4@justin.erols.com> Subject: Re: ISPACs Right, so instead of my customers having to renumber if I want to leave my upstream provider, my customers have to renumber if I want to leave the ISPAC I am in. To use your words, "just like today". That's true. However, if your customers want to change to another provider, they may be able to do so without renumbering (modulo sufficient local aggregation). 1) I am buying bandwidth from the person running an interconnect, in which case they become my provider, "just like today". And this person works for you indirectly, through the ISPAC administration, so they report to you. So you exert control over it. Unlike today. 2) Other members of the ISPAC's data cross my network to get to the ISPAC interconnect, and my traffic transits their network to get to the interconnect, Only if you take the mutual transit model. If you're sensitive to this, you should pursue the multiple independent interconnect model, as I suggested. effectively allowing my competitors to use my potentially better connectivity, and I become dependant on their network to make certain that my users connectivity isn't affected. I believe that I covered the reasons that people may be uncomfortable with that in detail before. And it effectively allows you to use your competitors potentially better connectivity. And they become dependent on your network to make certain that their users connectivity isn't affected. Sounds to me that you're not willing to trust. Even if there are contracts. That's ok by me, but I don't think that's the norm. Yes, and today I do not enter into agreements with my direct competitors where They have the ability to destroy connectivity for all of my customers to the entire internet, They do not have that ability if you either maintain your own upstream connection or you use a common upstream connection. Note that today they have that capability and you do NOT have the agreement. So.... it seems that legal agreements make you less comfortable, not more. unless I am buying transi from them, and even then it is a deal between my comapny and a single company who I selected, not some whacked consortium where I may or may not have say as to who has the ability to affect my traffic. You clearly have say: you join, you vote (assuming that's the political model). If you really don't like it, you vote with your feet. Yes, BGP peers /could/ do the same thing to me, but its a lot easier for me to turn off a peering session than instantaneously renumber my network. Excuse me, but anyone can hose you even not being a peer by simply injecting your prefixes from a black hole. I can take my handy-dandy WG packet generator and my T3 and take you out from wherever. So it's a big bad world out there regardless. At least with a piece of paper, you have a leg to stand on in court.... Yes, but such a lawsuit would likely be considered frivolous. Unless I was maliciously attacking my competitor via ping floods or something of the like, it would be quite difficult for them to launch a lawsuit that would be considered other than frivilous in a US court. So I guess I'm unclear on what you're worry is. If it's not malicious conduct, is it only incompetent conduct? If so, why does the common interconnect model not fix things? What happens when my routers have problems (and this is something that has happened on every complex backbone I have ever seen)? Hopefully they call you instead of suing you. Kinda like they should be doing right now. ;-) Until such a document exists we are wasting our time on this proposal, noone will use it. Even if such a document exists, no one will use the document. They'll want their own. Geeze, you don't spend much time with lawyers do you? You haven't seen the "well, this document won't do at all until I add some gratuitous changes and billable hours"? Tony, why don't you go propose this on inet-access where all of the people who would actually become members of these ISPACs actually are, instead of over here on cidrd where most of the members already receive space directly from the regional registry of their choice? One hurdle at a time, thank you. ;-) Tony   Received: from cnri by ietf.org id aa03955; 6 Dec 96 1:40 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa03745; 6 Dec 96 1:40 EST Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id QAA05483 for ; Fri, 6 Dec 1996 16:40:08 +1100 Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.7.3/8.7.3) with ESMTP id AAA18101; Fri, 6 Dec 1996 00:38:39 -0500 (EST) Message-Id: <199612060538.AAA18101@brookfield.ans.net> To: Tony Li cc: curtis@ans.net, nanog@merit.edu, cidrd@iepg.org, metro@nlanr.net Reply-To: curtis@ans.net Subject: Re: ISPACs In-reply-to: Your message of "Wed, 04 Dec 1996 17:10:31 PST." <199612050110.RAA18589@chimp.jnx.com> Date: Fri, 06 Dec 1996 00:38:39 -0500 From: Curtis Villamizar In message <199612050110.RAA18589@chimp.jnx.com>, Tony Li writes: > > I can't see how ISPACs are anything but a NOOP. If members of the > ISPAC connect to different providers then aggregation can't be > performed. > > ? Why not? Yes, they have to provide transit to each other for the full > ISPAC prefix.... > > If the smaller providers aggregate they have to all buy transit from > the same provider or agree to transit each others traffic or build > their own backbone as an organization at T3 speed in order to peer > with other providers as a single entity. > > Yup. We expect the most common case would be to touch down at a common set > of interconnects and then peer with other providers. Yes, there are > details and many options to be considered... > > Other than leveraging buying power what purpose does the ISPAC serve? > > It allows us to allocate addresses to smaller ISPs (hey ma, I've got a Unix > box and three modems, I'm gonna be an ISP and get me a /17 from the NIC!) > in a larger block and provide aggregation across all of the ISPs. It > allows (some) users to change providers within the ISPAC and not have to > renumber. > > Do we need an RFC for this? > > IMO ISPACs would be almost a NOOP so the RFC would be a NOOP and we > have enough junk RFCs already. None of it isn't true so I certainly > won't waste energy fighting this if you want to push it through. > > Curtis, no one hates stupid wasteful RFCs more than I do. So I'll make you > a deal: if we talk this through (and I mean talk - not just an Ohta-style > declaration of incompetence, thank you) and folks think that it's > pointless, then I'll kill it myself. In return, I ask that you seriously > consider all of the angles. Fair 'nuf? > > Tony I think that putting together RFCs that propose that ISDs pursue certain legal and financial arrangements is well outside the scope of the operations area and the IETF for that matter. I don't see this as an allocation issue or a technical issue wrt policy routing. As is applies to operating a small provider and a potential means to cooperate with other small providers by forming some sort of consortium it maybe could be considered an operations area item. I think what you have here is out of scope. Sorry if my note seemed like an out of hand dismissal but I just don't see that this works from a business standpoint and I also think the IETF is the wrong forum for proposing a style of consortium even if it was a great idea. I'll be quiet now and let others comment. Curtis   Received: from cnri by ietf.org id aa06441; 6 Dec 96 2:44 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa04966; 6 Dec 96 2:44 EST Received: from smtp1.erols.com (smtp1.erols.com [205.252.116.101]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id RAA06855 for ; Fri, 6 Dec 1996 17:28:19 +1100 Received: from justin.erols.com (justin.erols.com [205.252.116.48]) by smtp1.erols.com (8.7.5/8.7.3) with SMTP id VAA18984 for ; Thu, 5 Dec 1996 21:43:11 -0500 (EST) Message-Id: <3.0b36.32.19961205214806.013c0d7c@justin.erols.com> X-Sender: justin@justin.erols.com X-Mailer: Windows Eudora Pro Version 3.0b36 (32) Date: Thu, 05 Dec 1996 21:48:07 -0500 To: cidrd@iepg.org From: "Justin W. Newton" Subject: Re: ISPACs Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Well, since I seem to be the only person who holds my point of view, I suppose I'll stop posting after this (at least noone has mailed me and told me to shutup yet, or asked that I be removed from the list ;) At 05:30 PM 12/5/96 -0800, Tony Li wrote: > > Right, so instead of my customers having to renumber if I want to leave my > upstream provider, my customers have to renumber if I want to leave the > ISPAC I am in. To use your words, "just like today". > >That's true. However, if your customers want to change to another >provider, they may be able to do so without renumbering (modulo sufficient >local aggregation). Assuming that they move to a provider who is a member of the same ISPAC as I am, and that the aggreagtion inside of an individual ISPAC isn't important to the members. Yes, it could be possible. > > 1) I am buying bandwidth from the person running an interconnect, in which > case they become my provider, "just like today". > >And this person works for you indirectly, through the ISPAC administration, >so they report to you. So you exert control over it. Unlike today. As opposed to today where I write them a check and they work for me indirectly as well? > effectively allowing my competitors to use my potentially > better connectivity, and I become dependant on their network to make > certain that my users connectivity isn't affected. I believe that I > covered the reasons that people may be uncomfortable with that in detail > before. > >And it effectively allows you to use your competitors potentially better >connectivity. And they become dependent on your network to make certain >that their users connectivity isn't affected. > Exactly, this doesn't seem to be a position I would like to enter into. One provider or the other is going to have better connectivity, and this will effectively even out that connecitivity, which encourages me as a provider in the ISPAC to go with the lowest cost connectivity I can find and then piggy back off of other who have better connectivity. (Yes, I do know that there could be "connectivity requirements" for joining the ISPAC, but we all know a t-1 isn't a t-1 isn't a t-1, there are differences). >Sounds to me that you're not willing to trust. Even if there are >contracts. That's ok by me, but I don't think that's the norm. > > Yes, and today I do not enter into agreements with my direct competitors > where They have the ability to destroy connectivity for all of my customers > to the entire internet, > >They do not have that ability if you either maintain your own upstream >connection or you use a common upstream connection. Note that today they >have that capability and you do NOT have the agreement. So.... it seems >that legal agreements make you less comfortable, not more. Right, but even if I maintain my own upstream connection I am at the mercy of anyone else's upstream connection who is announcing thwe agregate block which contain my IP's. >You clearly have say: you join, you vote (assuming that's the political >model). If you really don't like it, you vote with your feet. Right, the same as I can today with an upstream provider. Basically what it seems that you are proposing is to some extent replacing dependance on an upstream provider with the ISPAC for IP address continuity. > > Yes, BGP peers /could/ do the same thing to > me, but its a lot easier for me to turn off a peering session than > instantaneously renumber my network. > >Excuse me, but anyone can hose you even not being a peer by simply >injecting your prefixes from a black hole. I can take my handy-dandy WG >packet generator and my T3 and take you out from wherever. So it's a big >bad world out there regardless. At least with a piece of paper, you have a >leg to stand on in court.... Yes, you can, and such an action is definately malicious, and likely illegal (like go to jail illegal). It is a lot easier for someone to do such a thing and have it look like an accident if they are advertising your blocks /with your consent/. Am I not making the difference clear, or am I overestimating the risk I believe I would be at if I undertook such a course of action. > > Yes, but such a lawsuit would likely be considered frivolous. Unless I was > maliciously attacking my competitor via ping floods or something of the > like, it would be quite difficult for them to launch a lawsuit that would > be considered other than frivilous in a US court. > >So I guess I'm unclear on what you're worry is. If it's not malicious >conduct, is it only incompetent conduct? If so, why does the common >interconnect model not fix things? Its mailicious content which could be masked as simply incometent, its incompetence which I would normally not have to be associated with that I now will be. (I trust MCI to be able to hire competent network engineers, have a 24 hr NOC, care if their name is smeared on NANOG, etc etc, the same does not hold true for Mom's Bait Tackle and IP Connectivity). A common interconnect model does improve things, but that takes us back to a provider based model where the people running the interconnect are a provider, which leaves us at the current model, no different. > > Until such a document exists we are wasting our time on this > proposal, noone will use it. > >Even if such a document exists, no one will use the document. They'll want >their own. Geeze, you don't spend much time with lawyers do you? You >haven't seen the "well, this document won't do at all until I add some >gratuitous changes and billable hours"? Thats fine, what I am looking for is something which could be used as a basis on which we can reach general consensus that this is something that we would be willing to use in a modified form. I don't want the details of the document, just the basic rules that people would agree to play by. I don't believe that even these basic rules could be agreed upon. > > Tony, why don't you go propose this on > inet-access where all of the people who would actually become members of > these ISPACs actually are, instead of over here on cidrd where most of the > members already receive space directly from the regional registry of their > choice? > >One hurdle at a time, thank you. ;-) It seems like that would be the logical place to do this though. I am adding input here, but quite frankly, this won't affect me one way or the other if it does happen. If you fo to a mailing list which has people on it who would actually /do/ this possibly you might get better participation than just me. Justin Newton Network Architect Erol's Internet Services   Received: from cnri by ietf.org id aa06793; 6 Dec 96 2:50 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa05092; 6 Dec 96 2:50 EST Received: from red.jnx.com (red.jnx.com [208.197.169.254]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id RAA07361 for ; Fri, 6 Dec 1996 17:50:46 +1100 Received: from chimp.jnx.com (chimp.jnx.com [208.197.169.246]) by red.jnx.com (8.8.3/8.8.3) with ESMTP id WAA03642; Thu, 5 Dec 1996 22:50:10 -0800 (PST) Received: (from tli@localhost) by chimp.jnx.com (8.7.6/8.7.3) id WAA21566; Thu, 5 Dec 1996 22:49:56 -0800 (PST) Date: Thu, 5 Dec 1996 22:49:56 -0800 (PST) Message-Id: <199612060649.WAA21566@chimp.jnx.com> From: Tony Li To: curtis@ans.net CC: curtis@ans.net, nanog@merit.edu, cidrd@iepg.org, metro@nlanr.net In-reply-to: <199612060538.AAA18101@brookfield.ans.net> (message from Curtis Villamizar on Fri, 06 Dec 1996 00:38:39 -0500) Subject: Re: ISPACs I think that putting together RFCs that propose that ISDs pursue certain legal and financial arrangements is well outside the scope of the operations area and the IETF for that matter. I don't see this as an allocation issue or a technical issue wrt policy routing. As is applies to operating a small provider and a potential means to cooperate with other small providers by forming some sort of consortium it maybe could be considered an operations area item. I think what you have here is out of scope. Curtis, I think you miss the point. The goal is to solve technical problems (aggregation, renumbering). The side effects are legal and financial and we get blasted if we _don't_ discuss them. Years of CIDR bashing has made us, uh, somewhat sensitive to this. So this time, we're trying to discuss those issues up front. Tony   Received: from cnri by ietf.org id aa07963; 6 Dec 96 4:00 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa06800; 6 Dec 96 4:00 EST Received: from red.jnx.com (red.jnx.com [208.197.169.254]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id TAA09037 for ; Fri, 6 Dec 1996 19:01:17 +1100 Received: from chimp.jnx.com (chimp.jnx.com [208.197.169.246]) by red.jnx.com (8.8.3/8.8.3) with ESMTP id AAA06204; Fri, 6 Dec 1996 00:01:06 -0800 (PST) Received: (from tli@localhost) by chimp.jnx.com (8.7.6/8.7.3) id AAA22042; Fri, 6 Dec 1996 00:00:52 -0800 (PST) Date: Fri, 6 Dec 1996 00:00:52 -0800 (PST) Message-Id: <199612060800.AAA22042@chimp.jnx.com> From: Tony Li To: justin@erols.com CC: cidrd@iepg.org In-reply-to: <3.0b36.32.19961205214806.013c0d7c@justin.erols.com> Subject: Re: ISPACs Justin, Right, but even if I maintain my own upstream connection I am at the mercy of anyone else's upstream connection who is announcing thwe agregate block which contain my IP's. So, if that's a concern, the ISPAC administration can simply dictate that the prefix only be announced by the common interconnect boxes. Right, the same as I can today with an upstream provider. Basically what it seems that you are proposing is to some extent replacing dependance on an upstream provider with the ISPAC for IP address continuity. Not replacing: adding another option. None of this precludes folks having an upstream provider instead of, or as well as ISPAC connectivity. Yes, you can, and such an action is definately malicious, and likely illegal (like go to jail illegal). It is a lot easier for someone to do such a thing and have it look like an accident if they are advertising your blocks /with your consent/. Am I not making the difference clear, or am I overestimating the risk I believe I would be at if I undertook such a course of action. What's not clear is simple: you only have to give your consent to advertise the shared prefix to the ISPAC administration. This need not imply that any other ISPAC member advertise the prefix. Given that the ISPAC administration is not a competitor, why is there sensitivity? Yes, you don't have the control that you would over a direct employee, but it would seem that this would alleviate fears of feigned incompetence. A common interconnect model does improve things, but that takes us back to a provider based model where the people running the interconnect are a provider, which leaves us at the current model, no different. I don't follow your leap here to the people running the interconnect being a separate provider. They're providing a room and bandwidth and mebbe routing services under contract to the ISPAC (as a group). Does that make them a competitor? Is MFS a competitor because of MAE-East? Tony   Received: from cnri by ietf.org id aa11437; 6 Dec 96 7:06 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa09717; 6 Dec 96 7:05 EST Received: from roam.psg.com (roam.psg.com [204.119.8.3]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id WAA11647 for ; Fri, 6 Dec 1996 22:10:29 +1100 Received: by roam.psg.com id m0vVyA4-000IVRC; Fri, 6 Dec 96 03:09 PST (Smail3.1.29.1#2) Message-Id: Date: Fri, 6 Dec 96 03:09 PST From: Randy Bush To: Geoff Huston Cc: Hank Nussbacher , cidrd@iepg.org Subject: Re: classless inaddr References: > I was under the impression that the draft was suitable for publication > as a BCP as was. But its now a DNSIND call I suppose. The authors recently issued a new draft, but the change was not, IMIHO, sufficient to warrant a new last call in dnsind or IESG. randy   Received: from cnri by ietf.org id aa11283; 7 Dec 96 3:12 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa03685; 7 Dec 96 3:12 EST Received: from red.jnx.com (red.jnx.com [208.197.169.254]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id SAA05131 for ; Sat, 7 Dec 1996 18:05:52 +1100 Received: from chimp.jnx.com (chimp.jnx.com [208.197.169.246]) by red.jnx.com (8.8.3/8.8.3) with ESMTP id XAA24881; Fri, 6 Dec 1996 23:05:40 -0800 (PST) Received: (from tli@localhost) by chimp.jnx.com (8.7.6/8.7.3) id XAA23657; Fri, 6 Dec 1996 23:05:24 -0800 (PST) Date: Fri, 6 Dec 1996 23:05:24 -0800 (PST) Message-Id: <199612070705.XAA23657@chimp.jnx.com> From: Tony Li To: justin@erols.com CC: cidrd@iepg.org In-reply-to: <3.0b36.32.19961206152653.0090e270@justin.erols.com> Subject: Re: ISPACs No, you are missing my point here. The packets ned to get to the interconnect somehow. There are 2 ways that the packets acn get to the interexchange (unless I am missing something very obvious) 1) The providers who are members of the ISPAC announce the aggregate announcement and then route the specific traffic for individual ISPs to the interconnect (or over the interconnect, whatever). 2) The interconnect itself advertisies the aggregate announcement and then routes to the ISPAC members. Setup 1) leads to the problem of dependancy on your competitors to get your traffic from the Internet at large. Setup 2) basically makes the interconnect provider your upstream provider, the same as Sprint, MCI or UUNET would be. What am I missing? (Please use small words as I am obviously missing what you are trying to teach me.) I was suggesting setup 2, as that would seem to be what you'd be most comfortable with. Except that the "interconnect provider" _is_ the ISPAC administration. I'm missing why you're uncomfortable with this. Tony   Received: from cnri by ietf.org id ah05039; 8 Dec 96 1:12 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa13959; 7 Dec 96 16:54 EST Received: from smtp2.erols.com (smtp2.erols.com [205.252.116.102]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id HAA11203 for ; Sun, 8 Dec 1996 07:54:45 +1100 Received: from justin.erols.com (justin.erols.com [205.252.116.48]) by smtp2.erols.com (8.7.5/8.7.3) with SMTP id PAA01525; Fri, 6 Dec 1996 15:21:45 -0500 (EST) Message-Id: <3.0b36.32.19961206152653.0090e270@justin.erols.com> X-Sender: justin@justin.erols.com X-Mailer: Windows Eudora Pro Version 3.0b36 (32) Date: Fri, 06 Dec 1996 15:26:54 -0500 To: Tony Li From: "Justin W. Newton" Subject: Re: ISPACs Cc: cidrd@iepg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 12:00 AM 12/6/96 -0800, Tony Li wrote: > A common > interconnect model does improve things, but that takes us back to a > provider based model where the people running the interconnect are a > provider, which leaves us at the current model, no different. > >I don't follow your leap here to the people running the interconnect being >a separate provider. They're providing a room and bandwidth and mebbe >routing services under contract to the ISPAC (as a group). Does that make >them a competitor? Is MFS a competitor because of MAE-East? No, you are missing my point here. The packets ned to get to the interconnect somehow. There are 2 ways that the packets acn get to the interexchange (unless I am missing something very obvious) 1) The providers who are members of the ISPAC announce the aggregate announcement and then route the specific traffic for individual ISPs to the interconnect (or over the interconnect, whatever). 2) The interconnect itself advertisies the aggregate announcement and then routes to the ISPAC members. Setup 1) leads to the problem of dependancy on your competitors to get your traffic from the Internet at large. Setup 2) basically makes the interconnect provider your upstream provider, the same as Sprint, MCI or UUNET would be. What am I missing? (Please use small words as I am obviously missing what you are trying to teach me.) > >Tony > > > Justin Newton Network Architect Erol's Internet Services   Received: from cnri by ietf.org id aj05039; 8 Dec 96 1:12 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa14464; 7 Dec 96 17:24 EST Received: from seagull.rtd.com (seagull.rtd.com [198.102.68.2]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id IAA11400 for ; Sun, 8 Dec 1996 08:34:53 +1100 Received: (from dsiegel@localhost) by seagull.rtd.com (8.7.5/8.7.3) id OAA06270; Sat, 7 Dec 1996 14:34:44 -0700 (MST) From: Dave Siegel Message-Id: <199612072134.OAA06270@seagull.rtd.com> Subject: Re: ISPACs To: "Justin W. Newton" Date: Sat, 7 Dec 1996 14:34:44 -0700 (MST) Cc: tli@jnx.com, cidrd@iepg.org In-Reply-To: <3.0b36.32.19961206152653.0090e270@justin.erols.com> from "Justin W. Newton" at Dec 6, 96 03:26:54 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > interconnect model does improve things, but that takes us back to a > > provider based model where the people running the interconnect are a > > provider, which leaves us at the current model, no different. > > > >I don't follow your leap here to the people running the interconnect being > >a separate provider. They're providing a room and bandwidth and mebbe > >routing services under contract to the ISPAC (as a group). Does that make > >them a competitor? Is MFS a competitor because of MAE-East? > > No, you are missing my point here. The packets ned to get to the > interconnect somehow. There are 2 ways that the packets acn get to the > interexchange (unless I am missing something very obvious) > > 1) The providers who are members of the ISPAC announce the aggregate > announcement and then route the specific traffic for individual ISPs to the > interconnect (or over the interconnect, whatever). > > 2) The interconnect itself advertisies the aggregate announcement and then > routes to the ISPAC members. > > Setup 1) leads to the problem of dependancy on your competitors to get your > traffic from the Internet at large. > > Setup 2) basically makes the interconnect provider your upstream provider, > the same as Sprint, MCI or UUNET would be. > > What am I missing? (Please use small words as I am obviously missing what > you are trying to teach me.) Justin, I think everyone is aware of the business issues involved in an ISPAC. Just because there is an RFC on the matter doesn't mean that Erols is going to have to join one, but what it does do is provide a document to registration organizations by which they may base allocations of IP space. There are certainly places where ISPs have teamed up to provide better service to the community at large, and that's perfectly fine. This document is for them. Dave -- Dave Siegel Sr. Network Engineer, RTD Systems & Networking (520)623-9663 x130 Network Consultant -- Regional/National NSPs dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/~dsiegel/ for an ISP."   Received: from cnri by ietf.org id ak05039; 8 Dec 96 1:12 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa15218; 7 Dec 96 18:25 EST Received: from smtp1.erols.com (smtp1.erols.com [205.252.116.101]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id JAA11732 for ; Sun, 8 Dec 1996 09:38:56 +1100 Received: from justin.erols.com (justin.erols.com [205.252.116.48]) by smtp1.erols.com (8.7.5/8.7.3) with SMTP id RAA29922; Sat, 7 Dec 1996 17:38:50 -0500 (EST) Message-Id: <3.0b36.32.19961207174419.00f30540@justin.erols.com> X-Sender: justin@justin.erols.com X-Mailer: Windows Eudora Pro Version 3.0b36 (32) Date: Sat, 07 Dec 1996 17:44:20 -0500 To: Tony Li From: "Justin W. Newton" Subject: Re: ISPACs Cc: cidrd@iepg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 11:05 PM 12/6/96 -0800, Tony Li wrote: >I was suggesting setup 2, as that would seem to be what you'd be most >comfortable with. Except that the "interconnect provider" _is_ the ISPAC >administration. I'm missing why you're uncomfortable with this. I'm not at all uncomfortable with that, that is more or less what the current internet model is right? I buy transit from someone and they give me IP addresses, how does this differ from the current provider based model aside from changing the name of the provider to ISPAC administration? > >Tony > > > Justin Newton Network Architect Erol's Internet Services   Received: from cnri by ietf.org id aa09854; 8 Dec 96 5:19 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa05212; 8 Dec 96 5:19 EST Received: from ohnasn07.houston.omnes.net (ohnasn07.houston.omnes.net [163.185.18.226]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id UAA14640 for ; Sun, 8 Dec 1996 20:29:07 +1100 Received: from [163.185.166.16] by ohnasn07.houston.omnes.net (post.office MTA v1.9.3 ID# 0-12122) with ESMTP id AAA21595; Sun, 8 Dec 1996 09:29:24 +0000 X-Sender: lodge@sndsn1.sedalia.sinet.slb.com Message-Id: In-Reply-To: <199612072134.OAA06270@seagull.rtd.com> References: <3.0b36.32.19961206152653.0090e270@justin.erols.com> from "Justin W. Newton" at Dec 6, 96 03:26:54 pm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 8 Dec 1996 03:28:43 -0600 To: Dave Siegel , "Justin W. Newton" From: Mathew Lodge Subject: RE: ISPACs Cc: tli@jnx.com, cidrd@iepg.org At 15:34 -0600 12/07/1996, Dave Siegel wrote: >I think everyone is aware of the business issues involved in an >ISPAC. > >Just because there is an RFC on the matter doesn't mean that Erols is >going to have to join one, but what it does do is provide a document to >registration organizations by which they may base allocations of IP space. I don't think everyone is aware of the business issues. This might sound like the beginning of a digression, but bear with me: dedicated Internet connections are primarily purchased by businesses (corporate customers). The key issues for ISPs when addressing this market are: 1. Differentiation of service 2. Ease of connection Issue (1) is addressed through providing additional features over and above simple global Internet connectivity and routing. These might be, for example, managed firewall connections or address translation. The latter, incidentally, can solve the renumbering problem for potential customers who have been leased addresses by another ISP. Issue (2) is largely addressed through packaging -- the bundling of the service itself with circuit provision, DTE equipment, managed router etc. etc. A single package from the ISP which covers all of this makes it much easier for a business customer to get connected. ISPAC is a technical solution to a technical problem. IMHO, it does not help with the key business issues that affect an ISP's bottom line the most: differentiation of service, and making customer connections easier. One might even argue that it provides less differentiation ("Look Ms Customer, you can switch to any of my competitors who are members of the same ISPAC without renumbering"). ISPAC also makes the sale harder. I cannot remember the last time I met a dedicated Internet access customer who even knew what route aggregation was, never mind why it is desirable. To sell the benefit of ISPAC, you have to backfill the customer's brain with all kinds of complex stuff they'd rather not know (and frankly, many don't care either). The ISP also needs a sales force that can understand the underpinnings of ISPAC and see the benefit of spending their time explaining it to the customer. A good sales person will balance this against simply closing the sale, collecting the commission and spending the time working on another prospect. This is not a trivial concern by any means. >There are certainly places where ISPs have teamed up to provide >better service to the community at large, and that's perfectly fine. >This document is for them. IMHO, these providers are a very small minority. If I'm right about that (and I have only my team's collective experience of setting up 14 ISPs in 10 countries to go on), then ISPAC is a technically interesting Internet draft, but no more. This is not intended as a side-swipe at Tony Li, BTW. I have great respect for Tony's motivation for writing the ISPAC draft, and it is excellently written with a clear understanding of the issues and is inventive in its methods of addressing them. I just don't have the faith that it will be implemented in enough places to be meaningful. To conclude: The ISPAC draft is fine as a goal for ISP collaboration. Its essential technical merit has not been questioned, as far as I can tell. The main bone of contention is how applicable it is to the business of being an ISP competing in an open market. AFAIK, the IETF considers engineering issues, not business issues, when determining whether to elevate a draft to an RFC. Therefore, if the technical and business issues are not considered inseparable, I respectfully suggest that the draft become an informational RFC. Comments welcome. Best regards, Mathew -- Mathew Lodge | "I think animal testing is a lodge@houston.omnes.net | terrible idea. They get all nervous Omnes, Houston, Texas, USA | and give the wrong answers" Phone: +1 281 275 8158 | -- A bit of Fry and Laurie   Received: from cnri by ietf.org id aa10956; 8 Dec 96 6:01 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa05706; 8 Dec 96 6:01 EST Received: from red.jnx.com (red.jnx.com [208.197.169.254]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id TAA14491 for ; Sun, 8 Dec 1996 19:52:39 +1100 Received: from chimp.jnx.com (chimp.jnx.com [208.197.169.246]) by red.jnx.com (8.8.3/8.8.3) with ESMTP id AAA18132; Sun, 8 Dec 1996 00:52:37 -0800 (PST) Received: (from tli@localhost) by chimp.jnx.com (8.7.6/8.7.3) id AAA26927; Sun, 8 Dec 1996 00:52:20 -0800 (PST) Date: Sun, 8 Dec 1996 00:52:20 -0800 (PST) Message-Id: <199612080852.AAA26927@chimp.jnx.com> From: Tony Li To: justin@erols.com CC: cidrd@iepg.org In-reply-to: <3.0b36.32.19961207174419.00f30540@justin.erols.com> Subject: Re: ISPACs >I was suggesting setup 2, as that would seem to be what you'd be most >comfortable with. Except that the "interconnect provider" _is_ the ISPAC >administration. I'm missing why you're uncomfortable with this. I'm not at all uncomfortable with that, that is more or less what the current internet model is right? I buy transit from someone and they give me IP addresses, how does this differ from the current provider based model aside from changing the name of the provider to ISPAC administration? Simple... rather than being at their business whim (admittedly as a customer), you have direct input. You're a partner. Tony   Received: from cnri by ietf.org id aa15787; 8 Dec 96 10:54 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa09242; 8 Dec 96 10:54 EST Received: from ns.att.com (ns.research.att.com [192.20.225.4]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id BAA17415 for ; Mon, 9 Dec 1996 01:45:05 +1100 Received: from research.att.com by ns; Sun Dec 8 09:44:02 EST 1996 Received: from raptor.research.att.com by research; Sun Dec 8 09:41:41 EST 1996 Received: from trust.research.att.com ([135.46.205.158]) by raptor.research.att.com (8.7.5/8.7) with SMTP id JAA16800; Sun, 8 Dec 1996 09:41:38 -0500 (EST) Message-Id: <2.2.32.19961208144116.008ce638@raptor.research.att.com> X-Sender: presnick@raptor.research.att.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 08 Dec 1996 09:41:16 -0500 To: Tony Li , justin@erols.com From: Paul Resnick Subject: Re: ISPACs Cc: cidrd@iepg.org > >I was suggesting setup 2, as that would seem to be what you'd be most > >comfortable with. Except that the "interconnect provider" _is_ the ISPAC > >administration. I'm missing why you're uncomfortable with this. > > I'm not at all uncomfortable with that, that is more or less what the > current internet model is right? I buy transit from someone and they give > me IP addresses, how does this differ from the current provider based model > aside from changing the name of the provider to ISPAC administration? > >Simple... rather than being at their business whim (admittedly as a >customer), you have direct input. You're a partner. Tony's answer suggests that an ISPAC is an upstream interconnect provider collectively owned by the downstream ISPs. If I'm interpreting correctly, then the proposal is a purely business innovation, and not a technical one at all. I have no problem with that, but I want to make sure I'm understanding correctly. ------------------------------------------------------------ Paul Resnick AT&T Labs Public Policy Research Room 2C-430A 908-582-5370 (voice) 600 Mountain Avenue 908-582-4113 (fax) P.O. Box 636 presnick@research.att.com Murray Hill, NJ 07974-0636 http://www.research.att.com/~presnick   Received: from cnri by ietf.org id aa29788; 8 Dec 96 20:14 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa17223; 8 Dec 96 20:14 EST Received: from red.jnx.com (red.jnx.com [208.197.169.254]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id LAA22949 for ; Mon, 9 Dec 1996 11:20:21 +1100 Received: from chimp.jnx.com (chimp.jnx.com [208.197.169.246]) by red.jnx.com (8.8.3/8.8.3) with ESMTP id QAA18538; Sun, 8 Dec 1996 16:20:18 -0800 (PST) Received: (from tli@localhost) by chimp.jnx.com (8.7.6/8.7.3) id QAA28014; Sun, 8 Dec 1996 16:19:59 -0800 (PST) Date: Sun, 8 Dec 1996 16:19:59 -0800 (PST) Message-Id: <199612090019.QAA28014@chimp.jnx.com> From: Tony Li To: presnick@research.att.com CC: justin@erols.com, cidrd@iepg.org In-reply-to: <2.2.32.19961208144116.008ce638@raptor.research.att.com> (message from Paul Resnick on Sun, 08 Dec 1996 09:41:16 -0500) Subject: Re: ISPACs Tony's answer suggests that an ISPAC is an upstream interconnect provider collectively owned by the downstream ISPs. If I'm interpreting correctly, then the proposal is a purely business innovation, and not a technical one at all. I have no problem with that, but I want to make sure I'm understanding correctly. Largely yes. It has some quasi-technical effects, such as address allocation to the ISPAC as an organizational entity. Tony   Received: from cnri by ietf.org id aa12462; 12 Dec 96 20:25 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa01415; 12 Dec 96 20:25 EST Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id KAA02074 for ; Fri, 13 Dec 1996 10:51:34 +1100 Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.7.3/8.7.3) with ESMTP id SAA16422; Thu, 12 Dec 1996 18:49:36 -0500 (EST) Message-Id: <199612122349.SAA16422@brookfield.ans.net> To: Tony Li cc: presnick@research.att.com, justin@erols.com, cidrd@iepg.org Reply-To: curtis@ans.net Subject: Re: ISPACs In-reply-to: Your message of "Sun, 08 Dec 1996 16:19:59 PST." <199612090019.QAA28014@chimp.jnx.com> Date: Thu, 12 Dec 1996 18:49:35 -0500 From: Curtis Villamizar In message <199612090019.QAA28014@chimp.jnx.com>, Tony Li writes: > > Tony's answer suggests that an ISPAC is an upstream interconnect provider > collectively owned by the downstream ISPs. If I'm interpreting correctly, > then the proposal is a purely business innovation, and not a technical one > at all. I have no problem with that, but I want to make sure I'm > understanding correctly. > > Largely yes. It has some quasi-technical effects, such as address > allocation to the ISPAC as an organizational entity. > > Tony Which is technically the same as allocation to an upstream provider which we already have. So this proposal offers nothing new from a technical standpoint and is purely a proposal for a business model. It is a business model that is arguably undesirable from a business standpoint. Regardless of whether or not it is a good business model, RFCs are not the way to propose business models. Curtis   Received: from cnri by ietf.org id aa28906; 13 Dec 96 11:24 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa16685; 13 Dec 96 11:24 EST Received: from dxmint.cern.ch (dxmint.cern.ch [137.138.26.76]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id CAA21061 for ; Sat, 14 Dec 1996 02:15:30 +1100 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id QAA20863; Fri, 13 Dec 1996 16:15:20 +0100 (MET) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA06525; Fri, 13 Dec 1996 16:15:13 +0100 Message-Id: <9612131515.AA06525@dxcoms.cern.ch> Subject: Re: ISPACs To: curtis@ans.net Date: Fri, 13 Dec 1996 16:15:13 +0100 (MET) From: Brian Carpenter CERN-CN Cc: tli@jnx.com, presnick@research.att.com, justin@erols.com, cidrd@iepg.org In-Reply-To: <199612122349.SAA16422@brookfield.ans.net> from "Curtis Villamizar" at Dec 12, 96 06:49:35 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Curtis, Regardless of whether ISPACs are a good or bad idea, and regardless whether RFCs are appropriate vehicles for proposing business models, Tony did not publish an RFC. The boiler plate on an I-D means what it says. I said in the open IAB that the IAB has advised the IESG that the IETF should not work on specific business models or practices, but may and should work on mechanisms which will support various business models. IMHO Tony's draft is on the OK side of this line. I agree however that there is a line we should not cross. Regards, Brian Carpenter (IAB Chair) (brian@dxcoms.cern.ch) voice +41 22 767 4967, fax +41 22 767 7155   Received: from cnri by ietf.org id aa25451; 14 Dec 96 15:16 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa18353; 14 Dec 96 15:16 EST Received: from ns.att.com (ns.research.att.com [192.20.225.4]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id GAA07513 for ; Sun, 15 Dec 1996 06:24:05 +1100 Received: from research.att.com by ns; Sat Dec 14 14:23:10 EST 1996 Received: from raptor.research.att.com by research; Sat Dec 14 14:22:04 EST 1996 Received: from trust.research.att.com ([135.46.192.175]) by raptor.research.att.com (8.7.5/8.7) with SMTP id OAA24129; Sat, 14 Dec 1996 14:21:59 -0500 (EST) Message-Id: <2.2.32.19961214192158.0074026c@raptor.research.att.com> X-Sender: presnick@raptor.research.att.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 14 Dec 1996 14:21:58 -0500 To: Brian Carpenter CERN-CN , curtis@ans.net From: Paul Resnick Subject: Re: ISPACs Cc: tli@jnx.com, justin@erols.com, cidrd@iepg.org >Curtis Villamizar wrote (in part): >Regardless of whether or not it is a good business model, >RFCs are not the way to propose business models. >Brian Carpenter wrote (in part): >I said in the open IAB that the IAB has advised the IESG that >the IETF should not work on specific business models or practices, >but may and should work on mechanisms which will support various >business models. A lot of IAB and IETF people are uncomfortable about the increasing discussion of business-related matters. I don't think either of the summaries above, however, capture the appropriate role for IETF. Nature of Innovation Nature of implication -------------------- --------------------- 1. Technical Technical 2. Technical Business 3. Business Technical 4. Business Business Presumably everyone agrees that items of type 1 (technical innovation with technical implication) should be discussed at IETF and be written about in RFCs. Brian and Curtis imply that items of type 2 are also acceptable for IETF discussion. I argue that we need also to include type 3, business innovations that have technical implications, such as number portability or scalable routing. It's my experience that technical people are often better at understanding business concepts than the reverse. As a result, we need to discuss, understand, and document the technical implications of business practices, rather than leaving these matters purely to the business types. I agree that we should exclude items of type 4. That is, IETF need not discuss the business implications of a business innovation. That means, in this case, that we can ignore such questions as whether a business-savvy ISP should join an ISPAC. We should, however, point out the level of technical interdependence among ISPs in an ISPAC, as Justin Newton has done. ------------------------------------------------------------ Paul Resnick AT&T Labs Public Policy Research Room 2C-430A 908-582-5370 (voice) 600 Mountain Avenue 908-582-4113 (fax) P.O. Box 636 presnick@research.att.com Murray Hill, NJ 07974-0636 http://www.research.att.com/~presnick   Received: from cnri by ietf.org id an07504; 15 Dec 96 1:10 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa24757; 14 Dec 96 20:59 EST Received: from red.jnx.com (red.jnx.com [208.197.169.254]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id MAA10379 for ; Sun, 15 Dec 1996 12:10:49 +1100 Received: from chimp.jnx.com (chimp.jnx.com [208.197.169.246]) by red.jnx.com (8.8.3/8.8.3) with ESMTP id RAA06235; Sat, 14 Dec 1996 17:10:40 -0800 (PST) Received: (from tli@localhost) by chimp.jnx.com (8.7.6/8.7.3) id RAA12441; Sat, 14 Dec 1996 17:10:12 -0800 (PST) Date: Sat, 14 Dec 1996 17:10:12 -0800 (PST) Message-Id: <199612150110.RAA12441@chimp.jnx.com> From: Tony Li To: presnick@research.att.com CC: brian@dxcoms.cern.ch, curtis@ans.net, tli@jnx.com, justin@erols.com, cidrd@iepg.org In-reply-to: <2.2.32.19961214192158.0074026c@raptor.research.att.com> (message from Paul Resnick on Sat, 14 Dec 1996 14:21:58 -0500) Subject: Re: ISPACs I argue that we need also to include type 3, business innovations that have technical implications, such as number portability or scalable routing. It's my experience that technical people are often better at understanding business concepts than the reverse. As a result, we need to discuss, understand, and document the technical implications of business practices, rather than leaving these matters purely to the business types. Paul, I think that the sole questions is whether type 3 discussions belong in the IETF. Frankly, I'm easy about the matter. The IETF provides a common and obvious "publishing house". As the IETF continues to decline, it's only natural that all interesting relevant work migrate away from the IETF to more appropriate forums. So the question isn't "type 3 or not type 3". The question is "where"? Tony   Received: from cnri by ietf.org id aa13667; 15 Dec 96 12:01 EST Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa13466; 15 Dec 96 12:01 EST Received: from dxmint.cern.ch (dxmint.cern.ch [137.138.26.76]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id DAA18418 for ; Mon, 16 Dec 1996 03:08:58 +1100 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id RAA13212; Sun, 15 Dec 1996 17:08:47 +0100 (MET) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA07789; Sun, 15 Dec 1996 17:08:45 +0100 Message-Id: <9612151608.AA07789@dxcoms.cern.ch> Subject: Re: ISPACs To: Paul Resnick Date: Sun, 15 Dec 1996 17:08:45 +0100 (MET) From: Brian Carpenter CERN-CN Cc: curtis@ans.net, tli@jnx.com, justin@erols.com, cidrd@iepg.org In-Reply-To: <2.2.32.19961214192158.0074026c@raptor.research.att.com> from "Paul Resnick" at Dec 14, 96 02:21:58 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Paul raises an interesting meta-issue, but wherever it fits, it isn't the cidrd list... maybe poised. When I have time, I'll post the IAB's view on this to the poised list, but it's not at the top of my priority list right now. Brian Carpenter >--------- Text sent by Paul Resnick follows: > > >Curtis Villamizar wrote (in part): > >Regardless of whether or not it is a good business model, > >RFCs are not the way to propose business models. > > >Brian Carpenter wrote (in part): > >I said in the open IAB that the IAB has advised the IESG that > >the IETF should not work on specific business models or practices, > >but may and should work on mechanisms which will support various > >business models. > > A lot of IAB and IETF people are uncomfortable about the increasing > discussion of business-related matters. I don't think either of the > summaries above, however, capture the appropriate role for IETF. > > Nature of Innovation Nature of implication > -------------------- --------------------- > 1. Technical Technical > 2. Technical Business > 3. Business Technical > 4. Business Business > > Presumably everyone agrees that items of type 1 (technical innovation with > technical implication) should be discussed at IETF and be written about in > RFCs. > > Brian and Curtis imply that items of type 2 are also acceptable for IETF > discussion. > > I argue that we need also to include type 3, business innovations that have > technical implications, such as number portability or scalable routing. It's > my experience that technical people are often better at understanding > business concepts than the reverse. As a result, we need to discuss, > understand, and document the technical implications of business practices, > rather than leaving these matters purely to the business types. > > I agree that we should exclude items of type 4. That is, IETF need not > discuss the business implications of a business innovation. That means, in > this case, that we can ignore such questions as whether a business-savvy ISP > should join an ISPAC. We should, however, point out the level of technical > interdependence among ISPs in an ISPAC, as Justin Newton has done. > > ------------------------------------------------------------ > Paul Resnick AT&T Labs > Public Policy Research Room 2C-430A > 908-582-5370 (voice) 600 Mountain Avenue > 908-582-4113 (fax) P.O. Box 636 > presnick@research.att.com Murray Hill, NJ 07974-0636 > http://www.research.att.com/~presnick > >   Received: from cnri by ietf.org id aa15825; 19 Dec 96 17:27 EST Received: from merit.edu by CNRI.Reston.VA.US id aa22860; 19 Dec 96 17:27 EST Received: (from daemon@localhost) by merit.edu (8.8.4/merit-2.0) id QAA10571 for idr-outgoing; Thu, 19 Dec 1996 16:47:08 -0500 (EST) Received: from idrp.merit.net (skh@idrp.merit.edu [198.108.60.89]) by merit.edu (8.8.4/merit-2.0) with ESMTP id QAA10565; Thu, 19 Dec 1996 16:47:04 -0500 (EST) From: skh@merit.edu Date: Thu, 19 Dec 1996 16:47:03 -0500 (EST) Message-Id: <199612192147.QAA28894@idrp.merit.net> To: idr@merit.edu Subject: Archive mistake Cc: skh@merit.edu Sender: owner-idr@merit.edu Precedence: bulk Alison Makin pointed out the archive on the mail list for idr/bgp is incorrect. Here's the correct archive pointers: Archive: ftp://ftp.merit.edu/mail.archives/idr hypertext: http://ww.merit.edu/mail.archives/html/idr (just started with current mail) A corrected charter will be posted to the ietf-web within a few days. Sue Hares   Received: from cnri by ietf.org id aa15991; 19 Dec 96 17:39 EST Received: from merit.edu by CNRI.Reston.VA.US id aa23163; 19 Dec 96 17:39 EST Received: (from daemon@localhost) by merit.edu (8.8.4/merit-2.0) id RAA13471 for idr-outgoing; Thu, 19 Dec 1996 17:18:22 -0500 (EST) Received: from idrp.merit.net (skh@idrp.merit.edu [198.108.60.89]) by merit.edu (8.8.4/merit-2.0) with ESMTP id RAA13466; Thu, 19 Dec 1996 17:18:17 -0500 (EST) From: skh@merit.edu Date: Thu, 19 Dec 1996 17:18:17 -0500 (EST) Message-Id: <199612192218.RAA29016@idrp.merit.net> To: idr@merit.edu Subject: Discussion on Multiprotocol Attribute Cc: skh@merit.edu, yakov@merit.edu Sender: owner-idr@merit.edu Precedence: bulk I'd like to suggest that the multiprotocol attribute discussion have a deadline of 1/15/97. So if you have comments on the draft, please send them by that time. Best wishes for a wonderful and peaceful holiday season! Sue Hares   Received: from cnri by ietf.org id aa26774; 19 Dec 96 4:27 EST Received: from merit.edu by CNRI.Reston.VA.US id aa05091; 19 Dec 96 4:27 EST Received: (from daemon@localhost) by merit.edu (8.8.4/merit-2.0) id DAA13380 for idr-outgoing; Thu, 19 Dec 1996 03:49:28 -0500 (EST) Received: from ns.cnc.ac.cn (ns.cnc.ac.cn [159.226.1.1]) by merit.edu (8.8.4/merit-2.0) with SMTP id DAA13369 for ; Thu, 19 Dec 1996 03:49:08 -0500 (EST) Received: from ftp.cnc.ac.cn by ns.cnc.ac.cn (SMI-8.6/SMI-SVR4) id QAA13968; Thu, 19 Dec 1996 16:53:35 +0800 From: skh@merit.edu Received: from merit.edu (ywlin@localhost) by ftp.cnc.ac.cn (950413.SGI.8.6.12/950213.SGI.AUTOCF) via UUCP id QAA01825 for idr@merit.edu; Thu, 19 Dec 1996 16:47:06 -0800 Received: from merit.edu (merit.edu [35.1.1.42]) by ftp.cnc.ac.cn (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA07010 for ; Thu, 19 Dec 1996 06:24:38 -0800 Received: from idrp.merit.net (skh@idrp.merit.edu [198.108.60.89]) by merit.edu (8.8.4/merit-2.0) with ESMTP id RAA07529 for ; Wed, 18 Dec 1996 17:26:17 -0500 (EST) Date: Wed, 18 Dec 1996 17:26:17 -0500 (EST) Message-Id: <199612182226.RAA26898@idrp.merit.net> To: ywlin@merit.edu Subject: Please send request to idr-request Sender: owner-idr@merit.edu Precedence: bulk Sue