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