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 | +----------------------------------------+
(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 | +----------------------------------------+
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
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, 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
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
On Mon, 29 Apr 1996, M. Christopher Davies wrote:
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
On Mon, 29 Apr 1996, Ali Marashi wrote: 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]
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, 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
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]
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)
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
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 | +----------------------------------------+
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.
All,
Paul A Vixie writes:
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.
Some providers have indicated that the route servers would better serve their needs if: 1) the RSs implemented only a subset of the policy expressed in the IRR and 2) the RSs could do proxy aggregation. The configurations of the RSs support both of those requirements now. The policy language does not yet support this in a "standard" fashion, but that is being addressed in the RPS working group. The RA has implemented requirements that providers have when a provider communicates what is needed. I can't find any messages from Sean indicating what he would like to express but can't. The RA team is always willing to work with providers to meet their needs. --Elise
The RA has implemented requirements that providers have when a provider communicates what is needed. I can't find any messages from Sean indicating what he would like to express but can't. The RA team is always willing to work with providers to meet their needs.
There is one thing that the RS can't do. If A & B are doing 3rd party peering via the RS, the fact that the A/RS peering is up & working and that the B/RS peering is up & working unfortunately does not tell you if A & B can exchange packets. If A & B are peering directly, then the fact that the peering is up also tells you that they can exchange packets. Luckily this sort of breakage does not happen very often. Unluckily, if it does break, if can be really hard to diagnose. --asp@partan.com (Andrew Partan)
From: Andrew Partan <asp@partan.com> Luckily this sort of breakage does not happen very often. Unluckily, if it does break, if can be really hard to diagnose. Especially in the presence of a TelCo-supplied level 2 switching fabric like Frame Relay, SMDS, or ATM. Erik E. Fair apple!fair fair@apple.com
Luckily this sort of breakage does not happen very often. Unluckily, if it does break, if can be really hard to diagnose.
Especially in the presence of a TelCo-supplied level 2 switching fabric like Frame Relay, SMDS, or ATM.
No kidding. Or ethernet briding over ATM PVCs. Think of OSPF or ISIS and designated routers on not quite ethernets and the interesting things that can happen in face of partial connectivity (or half duplex PVCs). -:) --asp@partan.com (Andrew Partan)
There is one thing that the RS can't do.
If A & B are doing 3rd party peering via the RS, the fact that the A/RS peering is up & working and that the B/RS peering is up & working unfortunately does not tell you if A & B can exchange packets.
If A & B are peering directly, then the fact that the peering is up also tells you that they can exchange packets.
Luckily this sort of breakage does not happen very often. Unluckily, if it does break, if can be really hard to diagnose. --asp@partan.com (Andrew Partan)
It has happened at least a few times in the past month at MAE-East (islands of disconnectivity), of course. Avi
There is one thing that the RS can't do.
If A & B are doing 3rd party peering via the RS, the fact that the A/RS peering is up & working and that the B/RS peering is up & working unfortunately does not tell you if A & B can exchange packets.
If A & B are peering directly, then the fact that the peering is up also tells you that they can exchange packets.
Luckily this sort of breakage does not happen very often. Unluckily, if it does break, if can be really hard to diagnose.
This could happen at a non-broadcast media NAP such as ATM nap when the PVCs between RS-A & RS-B are up but the PVC between A-B is down. But it's less likely to happen on a broadcast media NAP. It'd be ideal that the RS is injected with some intellegence to detect the fact that A can no long talk to B directly and thus stop passing routes between A & B. This will avoid the problem. But as you pointed out, it rarely happens so it may not worth the effort. By the way, if we flip this example around a bit: if A & B peer with the RS in addition to peer directly with each other and the bgp session between A & B broke for some reason and the connection is still there (i.e. they do not have bgp session but still can exchange packets), A & B would benifit from the RS. --Jessica (speaking for myself)
Jessica Yu <jyy@ans.net> writes * This could happen at a non-broadcast media NAP such as ATM nap when the * PVCs between RS-A & RS-B are up but the PVC between A-B is down. But it's * less likely to happen on a broadcast media NAP. * * It'd be ideal that the RS is injected with some intellegence to detect the * fact that A can no long talk to B directly and thus stop passing routes betw * een * A & B. This will avoid the problem. But as you pointed out, it rarely * happens so it may not worth the effort. But the question is whether there will be more NBMA type NAPs in the future. Point to MultiPoint for BGP, I like it ;-) -Marten
In message <199605020457.AAA00182@home.partan.com>, Andrew Partan writes:
The RA has implemented requirements that providers have when a provider communicates what is needed. I can't find any messages from Sean indicating what he would like to express but can't. The RA team is always willing to work with providers to meet their needs.
There is one thing that the RS can't do.
If A & B are doing 3rd party peering via the RS, the fact that the A/RS peering is up & working and that the B/RS peering is up & working unfortunately does not tell you if A & B can exchange packets.
If A & B are peering directly, then the fact that the peering is up also tells you that they can exchange packets.
Luckily this sort of breakage does not happen very often. Unluckily, if it does break, if can be really hard to diagnose. --asp@partan.com (Andrew Partan)
Just because you don't BGP peer doesn't mean you should monitor reachability to your third party peers. The BGP mib is handy, but this is nothing a ping test can't detect. Too bad there is no LQM on broadcast media. Curtis
participants (17)
-
Ali Marashi -
Andrew Partan -
Avi Freedman -
bmanning＠isi.edu -
Curtis Villamizar -
Elise Gerich -
Enke Chen -
Erik E. Fair -
Jeff Young -
Jessica Yu -
M. Christopher Davies -
Marten Terpstra -
Matt Zimmerman -
Michael Dillon -
Nathan Stratton -
Paul A Vixie -
randy＠psg.com