Re: ISPACs
Curtis Villamizar <curtis@ans.net> Fri, 06 December 1996 06:40 UTC
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 <cidrd@iepg.org>; 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 <tli@jnx.com>
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 <curtis@ans.net>
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
- ISPACs Tony Li
- Re: ISPACs Curtis Villamizar
- Re: ISPACs Tony Li
- Re: ISPACs Justin W. Newton
- Re: ISPACs Vadim Antonov
- Re: ISPACs Tony Li
- Re: ISPACs Tony Li
- Re: ISPACs Stephen Stuart
- Re: ISPACs Vadim Antonov
- Re: ISPACs John W. Stewart III
- Re: ISPACs Justin W. Newton
- Re: ISPACs Tony Li
- Re: ISPACs Justin W. Newton
- Re: ISPACs Tony Li
- Re: ISPACs Curtis Villamizar
- Re: ISPACs Justin W. Newton
- Re: ISPACs Tony Li
- Re: ISPACs Tony Li
- Re: ISPACs Tony Li
- Re: ISPACs Justin W. Newton
- Re: ISPACs Dave Siegel
- Re: ISPACs Justin W. Newton
- RE: ISPACs Mathew Lodge
- Re: ISPACs Tony Li
- Re: ISPACs Paul Resnick
- Re: ISPACs Tony Li
- Re: ISPACs Curtis Villamizar
- Re: ISPACs Brian Carpenter CERN-CN
- Re: ISPACs Paul Resnick
- Re: ISPACs Tony Li
- Re: ISPACs Brian Carpenter CERN-CN