| So sprint will coperate at least to the extent that MCI, ANS, and UUNET | are already doing so? If Craig had previously pointed out that he would like to have gotten routes from us that would not be propagated unless specifically requested by us, then I don't think it would have been too difficult to have done the two line adjustment to our already-existing peerings with the two RSes at MAE-EAST in order for us to have shown up on the hallowed list in his message today. Of course, that would have also deprived you of a front-page Cook Report scandal, and several messages here on the NANOG list. So, think of this as job creation at work, maybe. | I'd think that is good news. Do you have any kind of time line, Sean? | June 1? July 1? Well, I went digging, and couldn't find any relevant email on the first pass. Perhaps such a message will find its way to the appropriate people (maybe for the second time, if we lost things on this end), so we know what routing information is wanted and where and when, and what exactly it will be used for. I see no difficulty with announcing routes to the RA specifically for gathering the sorts of statistics they have been thinking about. Indeed, I believe that I have made this clear in public places a number of times in the past. We now return you to the regularly scheduled making of mountains out of mole-hills. Sean. P.S.: SL-MAE-E uptime is 1 week, 4 days, 12 hours, 37 minutes System restarted by power-on at 10:28:06 EST Fri Mar 22 1996 BGP neighbor is 192.41.177.166, remote AS 2885, external link NEXT_HOP is always this router BGP version 4, remote router ID 192.41.177.166 BGP state = Established, table version = 2186252, up for 1w0d Last read 0:00:57, hold time is 180, keepalive interval is 60 seconds Minimum time between advertisement runs is 30 seconds Received 16570 messages, 0 notifications, 0 in queue Sent 16605 messages, 0 notifications, 0 in queue Incoming update network filter list is 112 Outgoing update network filter list is 95 Outgoing update AS path filter list is 35 Route map for incoming advertisements is RA Connections established 4; dropped 3 [moreover, we set the peering up more than a year ago]
Sean, Just so you can stop searching your archives....
Sean Doran writes:
[stuff deleted] Well, I went digging, and couldn't find any relevant email on the first pass. Perhaps such a message will find its way to the appropriate people (maybe for the second time, if we lost things on this end), so we know what routing information is wanted and where and when, and what exactly it will be used for.
I see no difficulty with announcing routes to the RA specifically for gathering the sorts of statistics they have been thinking about. Indeed, I believe that I have made this clear in public places a number of times in the past.
Sprintlink is already peering with the route servers at MAE-East. Please go ahead and announce full routes to both of those route servers at 1900 EST today, (April 3). The RA will respect your request to not propogate the routes. The routing information learned from Sprintlink will be used to generate reports such as: a) the internet routing table, b) daily count of prefixes announced and withdrawn, c) daily invalid route announcments, and d) trends in routing information. Since Sprintlink is not yet peering with the route servers at the AADS, PacBell and Sprint NAPs, please fill out the route server peering template (www.ra.net/.peering.template.html) for each of the other three NAP locations. As soon as the peering sessions are established, announce full routes to those route servers. The same conditions that are described (no propogation of routes and generation of reports) will apply. If you have any further questions, please send email to ra-team@merit.edu. If there are other organizations who wish to initiate peering sessions with the route servers, please fill out the template on the web page or send email to ra-team@merit.edu. This is good news, Sean. --Elise
participants (2)
-
Elise Gerich
-
Sean Doran