RE: ISPACs

[Mathew Lodge <[e-mail]>]

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
[e-mail]	| terrible idea. They get all nervous
Omnes, Houston, Texas, USA	| and give the wrong answers"
Phone: [phone]	| -- A bit of Fry and Laurie