Mailing List Archive

There are two good reasons to peer only with backbones of
comparable size:

1) technical -- this allows to do hot-potato routing with minimal
resulting delay assymetry

2) economical -- peering at IXP is favouring smaller folks in
cost/benefit game. For a large ISP the percentage of additional
destinations the small ISP offers is smaller, and so is the
benefit of peering. ANd extra peerings are far from "free".
They produce extra paths which need to be processed by routers,
and so translate in shorter lifetime of the equipment -- which
means very real money. It also reduces effectiveness of
aggregation and increases risk of catastrophic failures (large
ISPs spend significant part of engineering resources and practice
rather strict controls on configuration process to ensure sanity
of routing; they also have to _trust_ each other. Most of garbadge
in routing tables comes from small ISPs, and is usually hard to
fix (no 24hr NOC etc).

So the "three IXPs" limitation is specifically designed to ensure
equality of sizes (to a some extent), other provisions of BLIAs
("blia" is a common profanity in Russian, btw :) include 24hr NOC etc.

Thus, far from being anti-competitive restrictions those policies only
serve to level the playing field -- as players who skip investment
in infrastructure, engineering and operations would get unfair advantage
otherwise.

No sane NSP would refuse peering with a new nationwide DS-3 backbone --
providing that it is something more than hot air. The plank is going
to be raised to OC-3 pretty soon, though....

--vadim

> (2) Could anyone share opinions/facts regarding why organizations may or
> may not exchange routes via the Route Servers rather than direct peering
> relationships at the NAPs?

I know of no case where an organization "may not" exchange routes
with the Route Servers.

--
--bill

On Mon, 29 Apr 1996 bmanning@isi.edu wrote:

> > (2) Could anyone share opinions/facts regarding why organizations may or
> > may not exchange routes via the Route Servers rather than direct peering
> > relationships at the NAPs?
>
> I know of no case where an organization "may not" exchange routes
> with the Route Servers.

I did not mean to imply that an organization was "not allowed" to exchange
routes with the Route Servers. I was trying to learn why an organization
"may choose" or "may not choose" to exchange routes with the Route Servers
rather than use direct peering relationships with other organizations.

In other words, what is the value for an organization to utilize the Route
Servers? And if there is value, why is everyone not doing it?

Ali....

+----------------------------------------+
| Ali Marashi |
| interGlobe Networks, Inc. |
| phone: 206.623.2222 fax: 206.623.0885 |
| http://www.interglobe.com |
+----------------------------------------+

At 12:09 PM 4/29/96 -0700, Ali Marashi wrote:

>
>I did not mean to imply that an organization was "not allowed" to exchange
>routes with the Route Servers. I was trying to learn why an organization
>"may choose" or "may not choose" to exchange routes with the Route Servers
>rather than use direct peering relationships with other organizations.
>
>In other words, what is the value for an organization to utilize the Route
>Servers? And if there is value, why is everyone not doing it?
>

One detractor, to the best of my knowledge, is that the route servers are
not exactly 'dynamic', meaning that they are updated a couple of times
during the course of the day to reflect any changes in routing policy.
Therefore, the possibility for blackhole'ing packets exists.

I'm sure someone will correct me if I'm remiss. :-)

- paul

On Mon, 29 Apr 1996, Ali Marashi wrote:

>
> I had a few questions to direct to the group at large that I believe are
> of a "network operational" nature.
>
> (1) I have heard that Sprint and MCI currently require an organization to
> peer with them at a minimum of three exchange points, where one must be on
> a different coast. I have been unable to confirm this directly from the
> sources yet. Would anyone care to share what knowledge they have on the
> subject? Are any other large providers (e.g., ANS) adhering to similar
> policies? As Internet traffic increases across the large backbones, could
> this be a trend that continues with other providers?

Yep, and yes I think it will continue.

> (2) Could anyone share opinions/facts regarding why organizations may or
> may not exchange routes via the Route Servers rather than direct peering
> relationships at the NAPs?

Well, because say that Sprint and MCI would peer, a provider would only
just stay at one NAP. That provider could then sell large dedicated
connections and in a way do it on Sprint's and MCI's network. I think they
they are trying to keep a lot of startups like me from growing and being a
large competitor.

I think that if a provider only wants to peer at one point, that MCI and
Sprint should not peer, but I think that if a provider lays out a network
plan and works to say get a 2 more NAPs in say 6 months that they should
peer.


Nathan Stratton CEO, NetRail, Inc. Tracking the future today!
---------------------------------------------------------------------------
Phone (703)524-4800 NetRail, Inc.
Fax (703)534-5033 2007 N. 15 St. Suite 5
Email sales@netrail.net Arlington, Va. 22201
WWW http://www.netrail.net/ Access: (703) 524-4802 guest
---------------------------------------------------------------------------
"Therefore do not worry about tomorrow, for tomorrow will worry about
itself. Each day has enough trouble of its own." Matthew 6:34

----------
All,

>>In other words, what is the value for an organization to utilize the Route
>>Servers? And if there is value, why is everyone not doing it?
>
>One detractor, to the best of my knowledge, is that the route servers are
>not exactly 'dynamic', meaning that they are updated a couple of times
>during the course of the day to reflect any changes in routing policy.
>Therefore, the possibility for blackhole'ing packets exists.
>
>I'm sure someone will correct me if I'm remiss. :-)

It's possible to have a policy at the RA Route Server which is
equivalent to a policy on a router and which does not need to change
all that often (e.g., AS-path-based export policy). Of course,
when it does need to change, it's the RA which needs to execute
that change, which leads into what I think is the real issue:

Control.

Would you bet your business on a service run by someone other than
yourself? While the Route Server is interesting and useful technology
(and I'm assuming that we all understand why that may or may not
be so), and may become necessary at some point for those providers
without resources to deploy appropriate routers, I don't think most
organizations would outsource a critical piece of functionality
without business assurances that the vending party is accountable
for the quality of service it provides.

I do not wish to make any point about the current RA folks, but
rather highlight that it's just a basic business issue. Emotionally,
I certainly want to control my own destiny to the maximum extent
possible. From a business perspective, I believe it's essential.

Steve

On Mon, 29 Apr 1996, Nathan Stratton wrote:
> On Mon, 29 Apr 1996, Ali Marashi wrote:
> > (2) Could anyone share opinions/facts regarding why organizations may or
> > may not exchange routes via the Route Servers rather than direct peering
> > relationships at the NAPs?
>
> Well, because say that Sprint and MCI would peer, a provider would only
> just stay at one NAP. That provider could then sell large dedicated
> connections and in a way do it on Sprint's and MCI's network. I think they
> they are trying to keep a lot of startups like me from growing and being a
> large competitor.

I think you've completely missed the boat on 1) what it means to peer,
and 2) why one would peer with you.

The idea (and I may be wrong here) that the big 6 may or may not choose
to peer with you is because they have no contract to provide TRANSIT for
your packets, but will gladly accept your packets for MCI or Sprint
connected sites. The idea behind peering is that it is a shared dropoff
point, but not a free transit to wherever on the net you want to go.

If you peer, it is expected that you will not utilize MCI's (as an
example) network to talk to a non-MCI connected site on the other side of
the country just because you don't have a link at Mae-West. As a result
you wouldn't need any expensive circuits to build your network and you
could 'take' service from your competitors to deliver your packets.
Peering means sharing, not taking advantage of or using of someone else's
service or backbone to make a profit (although this does happen all too
often)

Number two, what benefit is it to MCI to peer with you since you
obviously want to rest on the backbones of the other providers and try
and not pay a network provider good money to build a backbone that you
don't have to manage? What traffic do you generate that would benefit
MCI from peering with you?

That, I believe, is the reason that people don't peer as readily as you
want them to.

Making a comment that the big 6 are restraining trade certainly won't win
you points with the people you're trying to get peering arrangements with.
Work cooperatively, not adversarily to get your peering arrangements. And
have a good reason for the big 6 to want to peer with you other than, 'I
want cheaper transit'

When you build a redundant, coast to coast network, will you deliver my
packets for free? I didn't think so.

(*back into the deep*)
---------------------------------------------------------------
Chris Davies http://www.i95.net Office: 202-541-9000
VCI FAX: 202-723-9504 24x7 Direct: 202-541-9006
---------------------------------------------------------------

On Mon, 29 Apr 1996, Nathan Stratton wrote:

> > (2) Could anyone share opinions/facts regarding why organizations may or
> > may not exchange routes via the Route Servers rather than direct peering
> > relationships at the NAPs?
>
> Well, because say that Sprint and MCI would peer, a provider would only
> just stay at one NAP. That provider could then sell large dedicated
> connections and in a way do it on Sprint's and MCI's network. I think they
> they are trying to keep a lot of startups like me from growing and being a
> large competitor.
>
> I think that if a provider only wants to peer at one point, that MCI and
> Sprint should not peer, but I think that if a provider lays out a network
> plan and works to say get a 2 more NAPs in say 6 months that they should
> peer.

I think that you will find it much easier to get Sprint, MCI et al. to
peer with you at multiple NAP's if you have a reputation and that
reputation is a good one. The people at the large NSP's are rightly
conservative at making new peering decisions because the network is now so
big and so important to customers that they cannot risk significant
network failure.

If you want to peer, you will have to prove that your actions will not
endanger the network fabric especially the fabric of the NSP who you
are negotiating peering with. This is not an unsolvable problem.

The first step is to develop technical competence in your staff. This is
more than just reading manuals although it would help to have large
portions of Cisco's manuals committed to memory. It also requires you to
actually operate a complex network fabric of your own for a long enough
period of time for the learned theory to become understood reality. Part
of this effort should include familiarising yourself with much of the
leading edge research found in RFC's and other documents published by
various RFC authors and researchers. Some of this is at ra.net, merit.edu,
nlanr.net and so on.

In addition you have to develop a reputation of competence and this
demands that you physically attend several NANOG meetings and perhaps some
IETF's. There is nothing that can establish a reputation better than
personal contact. Of course, once you become a face and not just an email
address, even the "no" responses to a peering request are likely to lead
to some more explanation of "why?" so that you can remedy the situation.

The time required to go through these rites of passage will also allow you
to get your national network infrastructure built out so it is not a loss.
You *CAN* operate a national (or even international) network without
peering agreements. You *CAN* grow into being an NSP. You may even
discover that there are some benefits to multiple bilateral
peering/exchange points as opposed to becoming yet another NSP at an
octopus-like NAP.

Of course, the above is only my HUMBLE opinion, your mileage may vary :-)

Michael Dillon Voice: +1-604-546-8022
Memra Software Inc. Fax: +1-604-546-3049
http://www.memra.com E-mail: michael@memra.com

On Mon, 29 Apr 1996, M. Christopher Davies wrote:

> On Mon, 29 Apr 1996, Nathan Stratton wrote:
> > On Mon, 29 Apr 1996, Ali Marashi wrote:
> > > (2) Could anyone share opinions/facts regarding why organizations may or
> > > may not exchange routes via the Route Servers rather than direct peering
> > > relationships at the NAPs?
> >
> > Well, because say that Sprint and MCI would peer, a provider would only
> > just stay at one NAP. That provider could then sell large dedicated
> > connections and in a way do it on Sprint's and MCI's network. I think they
> > they are trying to keep a lot of startups like me from growing and being a
> > large competitor.
>
> I think you've completely missed the boat on 1) what it means to peer,
> and 2) why one would peer with you.
>
> The idea (and I may be wrong here) that the big 6 may or may not choose
> to peer with you is because they have no contract to provide TRANSIT for
> your packets, but will gladly accept your packets for MCI or Sprint
> connected sites. The idea behind peering is that it is a shared dropoff
> point, but not a free transit to wherever on the net you want to go.

No I think you are vary wrong, I know what it is to peer, and I am not
askign for TRANSIT. Sprint and MCi will nto PEER unless you are at 3 NAPS.

> If you peer, it is expected that you will not utilize MCI's (as an
> example) network to talk to a non-MCI connected site on the other side of

No kiding.

> That, I believe, is the reason that people don't peer as readily as you
> want them to.

You have no idea.


Nathan Stratton CEO, NetRail, Inc. Tracking the future today!
---------------------------------------------------------------------------
Phone (703)524-4800 NetRail, Inc.
Fax (703)534-5033 2007 N. 15 St. Suite 5
Email sales@netrail.net Arlington, Va. 22201
WWW http://www.netrail.net/ Access: (703) 524-4802 guest
---------------------------------------------------------------------------
"Therefore do not worry about tomorrow, for tomorrow will worry about
itself. Each day has enough trouble of its own." Matthew 6:34

On Mon, 29 Apr 1996, Michael Dillon wrote:

> I think that you will find it much easier to get Sprint, MCI et al. to
> peer with you at multiple NAP's if you have a reputation and that
> reputation is a good one. The people at the large NSP's are rightly
> conservative at making new peering decisions because the network is now so
> big and so important to customers that they cannot risk significant
> network failure.

I don't think so show me a ISP that has setup peering with sprint this
year, and is only at one NAP.

> If you want to peer, you will have to prove that your actions will not
> endanger the network fabric especially the fabric of the NSP who you
> are negotiating peering with. This is not an unsolvable problem.

That is how it is will a lot of people still, but is not the case with
sprint and MCI.

> The first step is to develop technical competence in your staff. This is
> more than just reading manuals although it would help to have large
> portions of Cisco's manuals committed to memory. It also requires you to
> actually operate a complex network fabric of your own for a long enough
> period of time for the learned theory to become understood reality. Part
> of this effort should include familiarising yourself with much of the
> leading edge research found in RFC's and other documents published by
> various RFC authors and researchers. Some of this is at ra.net, merit.edu,
> nlanr.net and so on.
>
> In addition you have to develop a reputation of competence and this
> demands that you physically attend several NANOG meetings and perhaps some
> IETF's. There is nothing that can establish a reputation better than
> personal contact. Of course, once you become a face and not just an email
> address, even the "no" responses to a peering request are likely to lead
> to some more explanation of "why?" so that you can remedy the situation.
>
> The time required to go through these rites of passage will also allow you
> to get your national network infrastructure built out so it is not a loss.
> You *CAN* operate a national (or even international) network without
> peering agreements. You *CAN* grow into being an NSP. You may even
> discover that there are some benefits to multiple bilateral
> peering/exchange points as opposed to becoming yet another NSP at an
> octopus-like NAP.
>
> Of course, the above is only my HUMBLE opinion, your mileage may vary :-)

Well, I think that is how it should work, and that is what I look for
before I connect peers, but this is not what Sprint or MCI and more and
more providers are starting to do.

Nathan Stratton CEO, NetRail, Inc. Tracking the future today!
---------------------------------------------------------------------------
Phone (703)524-4800 NetRail, Inc.
Fax (703)534-5033 2007 N. 15 St. Suite 5
Email sales@netrail.net Arlington, Va. 22201
WWW http://www.netrail.net/ Access: (703) 524-4802 guest
---------------------------------------------------------------------------
"Therefore do not worry about tomorrow, for tomorrow will worry about
itself. Each day has enough trouble of its own." Matthew 6:34

The organizations that export/import routes via the
route servers may find:

1) the routers have fewer configured peers therefore resulting
in less load on the routers
2) the route servers have route flap dampening implemented thereby
insulating the peer from a high number of routing updates
3) the route servers do the routing computations which results
in freeing significant amounts of processing time on the peer
routers
4) a reduction in the time and energy (people resources) needed to
establish new peering relationships

--Elise

>Ali Marashi writes:
>
>
> I had a few questions to direct to the group at large that I believe are
> of a "network operational" nature.
>
> (1) I have heard that Sprint and MCI currently require an organization to
> peer with them at a minimum of three exchange points, where one must be on
> a different coast. I have been unable to confirm this directly from the
> sources yet. Would anyone care to share what knowledge they have on the
> subject? Are any other large providers (e.g., ANS) adhering to similar
> policies? As Internet traffic increases across the large backbones, could
> this be a trend that continues with other providers?
>
> (2) Could anyone share opinions/facts regarding why organizations may or
> may not exchange routes via the Route Servers rather than direct peering
> relationships at the NAPs?
>
> Thank you for any information/enlightenment.
> Ali....
>
> +----------------------------------------+
> | Ali Marashi |
> | interGlobe Networks, Inc. |
> | phone: 206.623.2222 fax: 206.623.0885 |
> | http://www.interglobe.com |
> +----------------------------------------+
>

Hi, all:
Let me add my humble opnions on engineering issues reagarding peering:

(1) There is a snowball effect for interconnects. If an organization
could simply connect to an interconnect and gain global
connectivity without paying for transit, why not? Can you
imagine an interconnect with 500 organizations?

Unrestricted peering policy would accelerate rolling of the
snowball, and lead to the collapse of an interconnect. In order
for Internet to survive, this snowball effect got to stop.

(2) There is no connectivity gain for a national provider to peer
with a single-attached organizaiton as all these organizations have
transit providers that are present at multiple interconnects.

(3) There is a huge investment involved to build a national backbone.
Many providers currently do "hot-potato" routing (closed-exit)
because of this cost. Peering with a single-attached organization
would require much more backbone investment as traffic to this
organization needs to be carried across the backbone, while the
cost for this single-attached organization would be small (one
DS3 to an interconnect).

Regarding the RS (I have many friends there, and they have done many
good work), let me echo the fundamental issues that Steve Heimlich
has pointed out, would you rather have your peering policy enforced by
yourself or by a third party? Would you rather develop a dependency
on a third party (which may not be there a few years down the road)
to deliver the critical service or depend on yourself?

-- Enke (speaking only for myself)

one thing that's been overlooked in this conversation is the fact that
routing in the internet between mci/sprint/etc... nsp's is asymmetric.
we route shortest exit to sprint, they route shortest exit to us. in
this way we share the cost of cross country transit. unless you're in
three naps across the country (east, west, and middle) that's kind of
hard to duplicate.

Jeff Young
young@mci.net

> Return-Path: nathan@netrail.net
> Return-Path: nanog-owner@merit.edu
> Received: from merit.edu (merit.edu [35.1.1.42]) by postoffice.Reston.mci.net (8.7.5/8.6.6) with ESMTP id AAA10529; Tue, 30 Apr 1996 00:14:19 -0400 (EDT)
> Received: (from daemon@localhost) by merit.edu (8.7.5/merit-2.0) id AAA07460 for nanog-outgoing; Tue, 30 Apr 1996 00:04:08 -0400 (EDT)
> Received: from netrail.net (nathan@netrail.net [205.215.6.3]) by merit.edu (8.7.5/merit-2.0) with ESMTP id AAA07454 for <nanog@merit.edu>; Tue, 30 Apr 1996 00:04:05 -0400 (EDT)
> Received: from localhost (nathan@localhost) by netrail.net (8.7.5/Netrail) with SMTP id XAA23252; Mon, 29 Apr 1996 23:59:35 -0400
> Date: Mon, 29 Apr 1996 23:59:35 -0400 (EDT)
> From: Nathan Stratton <nathan@netrail.net>
> To: "M. Christopher Davies" <mcd@onramp.i95.net>
> cc: Ali Marashi <amarashi@interglobe.com>, NANOG <nanog@merit.edu>
> Subject: Re: Peering Policies and Route Servers
> In-Reply-To: <Pine.BSI.3.91.960429214629.17032F-100000@onramp.i95.net>
> Message-ID: <Pine.LNX.3.92.960429235656.23033B-100000@netrail.net>
> MIME-Version: 1.0
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> Sender: owner-nanog@merit.edu
> Precedence: bulk
> Content-Length: 2204
>
> On Mon, 29 Apr 1996, M. Christopher Davies wrote:
>
> > On Mon, 29 Apr 1996, Nathan Stratton wrote:
> > > On Mon, 29 Apr 1996, Ali Marashi wrote:
> > > > (2) Could anyone share opinions/facts regarding why organizations may or
> > > > may not exchange routes via the Route Servers rather than direct peering
> > > > relationships at the NAPs?
> > >
> > > Well, because say that Sprint and MCI would peer, a provider would only
> > > just stay at one NAP. That provider could then sell large dedicated
> > > connections and in a way do it on Sprint's and MCI's network. I think they
> > > they are trying to keep a lot of startups like me from growing and being a
> > > large competitor.
> >
> > I think you've completely missed the boat on 1) what it means to peer,
> > and 2) why one would peer with you.
> >
> > The idea (and I may be wrong here) that the big 6 may or may not choose
> > to peer with you is because they have no contract to provide TRANSIT for
> > your packets, but will gladly accept your packets for MCI or Sprint
> > connected sites. The idea behind peering is that it is a shared dropoff
> > point, but not a free transit to wherever on the net you want to go.
>
> No I think you are vary wrong, I know what it is to peer, and I am not
> askign for TRANSIT. Sprint and MCi will nto PEER unless you are at 3 NAPS.
>
> > If you peer, it is expected that you will not utilize MCI's (as an
> > example) network to talk to a non-MCI connected site on the other side of
>
> No kiding.
>
> > That, I believe, is the reason that people don't peer as readily as you
> > want them to.
>
> You have no idea.
>
>
> Nathan Stratton CEO, NetRail, Inc. Tracking the future today!
> ---------------------------------------------------------------------------
> Phone (703)524-4800 NetRail, Inc.
> Fax (703)534-5033 2007 N. 15 St. Suite 5
> Email sales@netrail.net Arlington, Va. 22201
> WWW http://www.netrail.net/ Access: (703) 524-4802 guest
> ---------------------------------------------------------------------------
> "Therefore do not worry about tomorrow, for tomorrow will worry about
> itself. Each day has enough trouble of its own." Matthew 6:34
>
>

> To: NANOG <nanog@merit.edu>
> Subject: Re: Peering Policies and Route Servers
> Date: Tue, 30 Apr 1996 10:49:02 -0400
> From: Enke Chen <enke@mci.net>
> [...]
> Regarding the RS (I have many friends there, and they have done many
> good work), let me echo the fundamental issues that Steve Heimlich
> has pointed out, would you rather have your peering policy enforced by
> yourself or by a third party? Would you rather develop a dependency
> on a third party (which may not be there a few years down the road)
> to deliver the critical service or depend on yourself?

This sounds like an argument for an NSP to build their own routers.

(Oh,I forgot, that has already been tried...)

More seriously, I would like to think that the analysis performed by
the NSPs is a bit more detailed. Perhaps the challenges include:

o the routing arbiter not having a long-term track record as a vendor
against which to compare internal efforts, or as you mention
an uncertain future;

o the route servers don't save an NSP all that much work;

o the NSPs haven't bothered to do the analysis; or

o ...

-tjs


-tjs

In message <199604292016.NAA27332@lint.cisco.com>, Paul Ferguson writes:
> At 12:09 PM 4/29/96 -0700, Ali Marashi wrote:
>
> >
> >I did not mean to imply that an organization was "not allowed" to exchange
> >routes with the Route Servers. I was trying to learn why an organization
> >"may choose" or "may not choose" to exchange routes with the Route Servers
> >rather than use direct peering relationships with other organizations.
> >
> >In other words, what is the value for an organization to utilize the Route
> >Servers? And if there is value, why is everyone not doing it?
> >
>
> One detractor, to the best of my knowledge, is that the route servers are
> not exactly 'dynamic', meaning that they are updated a couple of times
> during the course of the day to reflect any changes in routing policy.
> Therefore, the possibility for blackhole'ing packets exists.
>
> I'm sure someone will correct me if I'm remiss. :-)
>
> - paul


Paul,

There is no possibility for blackholing packets. Blackholing means
advertising a route and then not delivering the packet.

The risk is that a new route or one that changed will not be
advertised until the next config cycle.

Curtis

I do not intend to dispute your general argument, though I reserve the right
to do so elsewhere/time <grin>. But there is one seemingly fallacious point
folk seem to be repeatedly making.

> If an organization could simply connect to an interconnect and gain global
> connectivity without paying for transit, why not?

As there are multiple peering points today, and not all providers are
attached to all points, even if one peers with everybody at one point, one
will not have global connectivity.

If one were to permit free peerage to anyone appearing at only one single
peering point, the lack of global connectivity available at a single peering
point would become even more extreme.

E.g. Mary's Homegrown ISP connected to MAE-Miami and not having a transit
provider would not have connectivity to Joe's Down Home Linux Lair which
does not buy transit yet peers with everyone at the Truckee NAP.

randy

Paul Ferguson (pferguso@cisco.com) on April 29:
> One detractor, to the best of my knowledge, is that the route servers are
> not exactly 'dynamic', meaning that they are updated a couple of times
> during the course of the day to reflect any changes in routing policy.
> Therefore, the possibility for blackhole'ing packets exists.
>
> I'm sure someone will correct me if I'm remiss. :-)

Yes, I will do that:-)

Route Servers are dynamic, they process upto 6000 routing updates a
minute (see http://compute.merit.edu/stats/mae-east/instability).

Route Servers are reconfigured with up to date policy 6 times a day,
i.e. every four hours. Hence, a brand new route registered in IRR may
not be announced by the route servers to the NSPs whose policies are
prefix based for up to at most 4 hours. I think this is what you are
referring to.

Cengiz

--
Cengiz Alaettinoglu Information Sciences Institute
(310) 822-1511 University of Southern California
http://www.isi.edu/~cengiz

At 10:12 AM 4/30/96 -0700, Cengiz Alaettinoglu wrote:

>
>Route Servers are dynamic, they process upto 6000 routing updates a
>minute (see http://compute.merit.edu/stats/mae-east/instability).
>
>Route Servers are reconfigured with up to date policy 6 times a day,
>i.e. every four hours. Hence, a brand new route registered in IRR may
>not be announced by the route servers to the NSPs whose policies are
>prefix based for up to at most 4 hours. I think this is what you are
>referring to.
>

Cengiz, thanks for the clarification.

- paul

> > >In other words, what is the value for an organization to utilize the Route
> > >Servers? And if there is value, why is everyone not doing it?
> >
> > One detractor, to the best of my knowledge, is that the route servers are
> > not exactly 'dynamic', meaning that they are updated a couple of times
> > during the course of the day to reflect any changes in routing policy.
> > Therefore, the possibility for blackhole'ing packets exists.
>
> There is no possibility for blackholing packets. Blackholing means
> advertising a route and then not delivering the packet.

I'm afraid that I did run into a situation where the route was advertised
and the packet was blackholed.

I started to peer with AS-2882 at the PB NAP, and I accepted routes
from it for another ISP (no finger pointing today -- sorry). Well, the
ISP didn't have the VC map config'd in their router, and that route
became preferred after a glitch somewhere in their network. Well, since
the med's were the same in the routes we were sending to them, they
preferred the PB NAP route after their glitch. Needless to say, not
a happy situation. Then, of course, there was yet another ISP we were
waiting for their router to be config'd, etc.

Well, I didn't have time to wait for my advisory to be updated, so,
brute force was utilized:

(config-router)# no neighbor 198.32.128.130

This was more out of frustration in that I had my config's ready and I
agreed to accept and give routes via the R/S. Needless to say, I'll
decline to accept/advertise to that peer until I can ping them.

Yes, I know this is more of a initial config issue, but the route servers
were "in the way" at this point. Can You Say "neighbor x weight 1" next
time :)

rob gutierrez / internex information services

peerage, like sex these years, has a great potential for the transmission
of disease. so one is very careful about with whom one peers. the route
servers are more like a bath house, you're excahnging bodily fluids with
every and any body.

some exchanges have multi-lats. how many are actually used by the bigger
players and how many are ignored in favor of multiple bi-lats?

randy

> The organizations that export/import routes via the route servers may find:
>
> 1) the routers have fewer configured peers therefore resulting
> in less load on the routers
> 2) the route servers have route flap dampening implemented thereby
> insulating the peer from a high number of routing updates
> 3) the route servers do the routing computations which results
> in freeing significant amounts of processing time on the peer routers
> 4) a reduction in the time and energy (people resources) needed to
> establish new peering relationships
>
> --Elise

I, as an example of an "organization" as described above, have found these
things to be true. The startup transient is high -- all those this-objects
and that-objects. But once it's up and running, adding route relationships
is much easier using the route server than by adding BGP sessions.

Of course, I don't do anything complicated. I understand that Sean and
others have found that they need to do things with their route import and
export rules that the route servers don't have a way of expressing. Perhaps
if I were running a net as large as Sean's I would have his troubles.

On Mon, 29 Apr 1996, M. Christopher Davies wrote:

> On Mon, 29 Apr 1996, Nathan Stratton wrote:
> > On Mon, 29 Apr 1996, Ali Marashi wrote:
> > > (2) Could anyone share opinions/facts regarding why organizations may or
> > > may not exchange routes via the Route Servers rather than direct peering
> > > relationships at the NAPs?
> > Well, because say that Sprint and MCI would peer, a provider would only
> > just stay at one NAP. That provider could then sell large dedicated
> > connections and in a way do it on Sprint's and MCI's network. I think they
> > they are trying to keep a lot of startups like me from growing and being a
> > large competitor.
> I think you've completely missed the boat on 1) what it means to peer,
> and 2) why one would peer with you.
>
> The idea (and I may be wrong here) that the big 6 may or may not choose
> to peer with you is because they have no contract to provide TRANSIT for
> your packets, but will gladly accept your packets for MCI or Sprint
> connected sites. The idea behind peering is that it is a shared dropoff
> point, but not a free transit to wherever on the net you want to go.

This has very little to do with peering...I know of no NSP's who are
offering transit service via peering at exchange points. The fact is, not
everyone is "gladly" offering routes to their customers. I won't go into
the various technical, economic and political reasons why.

> If you peer, it is expected that you will not utilize MCI's (as an
> example) network to talk to a non-MCI connected site on the other side of
> the country just because you don't have a link at Mae-West. As a result
> you wouldn't need any expensive circuits to build your network and you
> could 'take' service from your competitors to deliver your packets.
> Peering means sharing, not taking advantage of or using of someone else's
> service or backbone to make a profit (although this does happen all too
> often)

True enough. And if the software side of the peering arrangement is
configured correctly, this will not happen.

> Number two, what benefit is it to MCI to peer with you since you
> obviously want to rest on the backbones of the other providers and try
> and not pay a network provider good money to build a backbone that you
> don't have to manage? What traffic do you generate that would benefit
> MCI from peering with you?

"Rest on the backbones of the other providers"? Hardly. Is it wrong to
use NSP X's backbone to reach customers of NSP X? This makes for a very
sketchy moral model of Internet operations. Is there really a question of
"benefit" here? Peering can only increase connectivity, not hinder it.
Setting aside the technological barriers to such an arrangement, an
optimal configuration would be one in which all routing entities peer with
one another at all available locations, so as to provide the shortest path
between routing communities. Assuming the peer knows the best route to
all destinations within its AS, it's a good bet that fewer miles and/or
hops are involved via a near exchange than via a distant one.

If NSP Y peers with NSP Z at MAE-East and MAE-West, and one of its
east-coast customers wants to reach a west-coast customer of NSP Z, whose
responsibility is it to backhaul the traffic to the opposite coast? What
about in the opposite direction? There's a lot of closest-exit routing
going on these days.

> Making a comment that the big 6 are restraining trade certainly won't win
> you points with the people you're trying to get peering arrangements with.
> Work cooperatively, not adversarily to get your peering arrangements. And
> have a good reason for the big 6 to want to peer with you other than, 'I
> want cheaper transit'

Transit is the use of a provider's backbone and peering arrangements to
reach "distant" neighbors (those outside of said provider's community).
Peering, in the traditional sense, will not accomplish this goal.

> When you build a redundant, coast to coast network, will you deliver my
> packets for free? I didn't think so.

Unless you decide to run connections to all of my customers or points of
presence, I don't think that can be avoided. Do any of our current peers
pay for the privilege of exchanging data without customers?

// Matt Zimmerman Chief of System Management NetRail, Inc.
// mdz@netrail.net sales@netrail.net
// (703) 524-4800 [voice] (703) 524-4802 [data] (703) 534-5033 [fax]

> > > (2) Could anyone share opinions/facts regarding why organizations may or
> > > may not exchange routes via the Route Servers rather than direct peering
> > > relationships at the NAPs?
> >
> > I know of no case where an organization "may not" exchange routes
> > with the Route Servers.
>
> I do, AS1800..
>
> --Peter

Hum... Lets looks at this for a bit.

27% whois 1800
SPRINT (ASN-ICMNET-2)

Autonomous System Name: ICM-Atlantic
Autonomous System Number: 1800

ICM is the NSF project for International Connection Mangment yes?
Are you intimating that the NSF ICM contract prohibits it from
working with the NSF RA project?

Perhaps someone from the NSF would be willing to give us a reading
here. I had thought that these two NSF projects were to work together
to improve the stability of the global Internet routing system.

I'd would appreciate some clarification here.

--
--bill

On Mon, 29 Apr 1996, Michael Dillon wrote:

> I think that you will find it much easier to get Sprint, MCI et al. to
> peer with you at multiple NAP's if you have a reputation and that
> reputation is a good one. The people at the large NSP's are rightly
> conservative at making new peering decisions because the network is now so
> big and so important to customers that they cannot risk significant
> network failure.
>
> If you want to peer, you will have to prove that your actions will not
> endanger the network fabric especially the fabric of the NSP who you
> are negotiating peering with. This is not an unsolvable problem.

There is no question of the risk involved in peering. Since caution is
most often the best way to approach risk, it needs no justification
either. What is being debated is whether or not the emerging policies of
large NSPs reflect this approach. I would have no objection to a
requirement of proof...it's requirements of money and resources that have
small corporations complaining.

[technical competence]
[networking experience]
[familiarity with current events]
> In addition you have to develop a reputation of competence and this
> demands that you physically attend several NANOG meetings and perhaps some
> IETF's. There is nothing that can establish a reputation better than
> personal contact. Of course, once you become a face and not just an email
> address, even the "no" responses to a peering request are likely to lead
> to some more explanation of "why?" so that you can remedy the situation.

These are all valuable resources in running an NSP...these are, in fact,
several of our goals here. Certainly some (most notably personal
appearances) are limited by available resources, but all are necessary to
some extent.

However...

- Is a small staff necessarily an incompetent one?
- Is a company which has operated on a small scale necessarily doomed to
failure in a large scale endeavor?
- Does a scarcity of resources necessarily indicate an inability to
efficiently utilize available resources?

These all seem to be generalizations made by peering policies which
discriminate against smaller providers. Meeting Sprint and MCI's peering
conditions requires only minimal competence. What it takes is money.

> The time required to go through these rites of passage will also allow you
> to get your national network infrastructure built out so it is not a loss.
> You *CAN* operate a national (or even international) network without
> peering agreements. You *CAN* grow into being an NSP. You may even
> discover that there are some benefits to multiple bilateral
> peering/exchange points as opposed to becoming yet another NSP at an
> octopus-like NAP.

For the record, I fully realize the value of peering at multiple exchange
points. :-) Though it seems to have been interpreted as such, my crusade
is not to win peering arrangements at a NAP. My whining serves the far
larger (and more interesting) purpose of pointing out the arguable wisdom
of certain policies (which just happen to be detrimental to the pursuit of
my goals).

// Matt Zimmerman Chief of System Management NetRail, Inc.
// mdz@netrail.net sales@netrail.net
// (703) 524-4800 [voice] (703) 524-4802 [data] (703) 534-5033 [fax]