- NANOG - lists.nanog.org

Re: Peering Policies and Route Servers
by John Curran 30 Apr '96

30 Apr '96

At 2:12 PM 4/30/96, Matt Zimmerman wrote: >... >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. I believe that the optimal configuration would actually involve only one routing entity and no peering at all. I'm pleased that instead we've implemented a model which (while not optimal) allows for a growing Internet service provider industry. Solutions which are optimal under one constraint tend to degenerate in the real world. Shortest-exit routing and equivalent distributed peering is used to avoid settlements for transit costs. If there's a strong demand for dissimiliar peering, then it's likely to appear with settlements. /John

2 1

Re: Inter-exchange media types
by Peter Lothberg 30 Apr '96

30 Apr '96

> Dtatacom tests were performed in the 10/100 setup. Obviously > the Fast ethernet switches had an advantage over the FDDI > switches since Fast ethernet and conventional ethernet work > with the same frame types. FDDI switches on the other hand > has to convert ethernet frames to FDDI frames and vice versa. > Todays NAPs in most cases are not 10/100 set up. It is more like > DS3/100/100 setup where routers are feeding traffic into the Gigaswitch > using FDDI and since HSSI and FDDI is using same MTU size, no > fragmentation is involved. Both 10 and 100 ethernet use 1500 byte mtu. And remember that the characteristics of a loaded exchange is very diffrent between ethernet and token-ring. ---Peter

2 1

Re: Peering Policies and Route Servers
by salo＠msc.edu 30 Apr '96

30 Apr '96

> To: NANOG <nanog(a)merit.edu> > Subject: Re: Peering Policies and Route Servers > Date: Tue, 30 Apr 1996 10:49:02 -0400 > From: Enke Chen <enke(a)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

3 2

Re: MFS buys UUNET.
by Paul Ferguson 30 Apr '96

30 Apr '96

The press release is on the UUNET homepage at http://www.uu.net. - paul At 09:56 AM 4/30/96 -0700, Rob Gutierrez wrote: >As somebody mentioned today, an AP wire story came across this morning >that MFS is _buying_ UUNET for $2 billion. Shareholders are looking at >getting 1.78 shares of MFS for each of their shares. Apparently, they >got 62% of the voting shareholders to agree (ie: who owns a couple >of large chunks of UUNET?). > >Remember that Microsoft already has their claws into UUNET for 13% :) > >The wire story was short on content. Noone of the on-line newspapers >have the story up yet. Needless to say, UUNET's gonna be inundated >with questions at I-World today. > >Speaking of which, I gotta go there right now ... :) > > rob gutierrez / internex information services > > >

1 0

enormous instabilities @ CA 0800 EDT daily?
by Sean Doran 30 Apr '96

30 Apr '96

I was looking over some trend graphs which I remember to look at from time to time and noticed that there recently has been a large level of instability between 7 and 9 a.m. Eastern (D.C.) time, with the worst period occurring at about 0800. The instability graphs that compute.merit.edu puts together shows a very similar trend, at least for the past few days. Is anyone else seeing this? If so, does anyone have any theories? I'd really like to see this fixed. Sean.

2 1

Re: Peering Policies and Route Servers
by Paul Ferguson 30 Apr '96

30 Apr '96

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

1 0

Re: Peering Policies and Route Servers
by Paul Ferguson 30 Apr '96

30 Apr '96

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

3 2

MFS buys UUNET.
by rmg＠internex.net 30 Apr '96

30 Apr '96

As somebody mentioned today, an AP wire story came across this morning that MFS is _buying_ UUNET for $2 billion. Shareholders are looking at getting 1.78 shares of MFS for each of their shares. Apparently, they got 62% of the voting shareholders to agree (ie: who owns a couple of large chunks of UUNET?). Remember that Microsoft already has their claws into UUNET for 13% :) The wire story was short on content. Noone of the on-line newspapers have the story up yet. Needless to say, UUNET's gonna be inundated with questions at I-World today. Speaking of which, I gotta go there right now ... :) rob gutierrez / internex information services

1 0

Sprints definition on NAPs (question)
by Marcos Della 30 Apr '96

30 Apr '96

Ok, I have been told repeatedly that I cannot peer with Sprint because I don't meet the three NAP list. Ok, what is considered a NAP by sprint? I'm in the process of putting a DS3 to SprintNAP so I assume that will count for one... PacNAP count? Mae-East or West? Whats the official list so that I don't have to keep bouncing routes for Sprint customers all over kingdom come or hope for route reflections on the various interconnect points... Also, once you do meet the criteria, who do you talk to? Talking to a Sprint salesman is like talking to a brick wall... Marcos -- ''' (o o) --------------------------oOO--(_)--OOo-------------------------- Marcos R. Della Email: mdella(a)InterNex.Net Director, Network Engineering InterNex Information Services Phone: 408/327-2250 http://www.internex.net/~mdella

4 3

Peer Groups vs. Individual Peers
by Jim Fleming 30 Apr '96

30 Apr '96

On Monday, April 29, 1996 2:19 PM, Michael Dillon[SMTP:michael@memra.com] wrote: @ On Mon, 29 Apr 1996, John Scoggin wrote: @ <snip> @ @ Just remember the plain English meaning of the word "peer". It refers to @ an individual who is at the same level as you. Same level of power (CEO @ vs. engineer), same level of skill (PhD vs undergrad) and so on. @ @ @ Michael Dillon Voice: +1-604-546-8022 It should come as no surprise to anyone that large companies mostly like to work with other large companies and small companies and individuals are not taken seriously unless they are members of a group that begins to take on some significance. As I have suggested before, I feel that individuals and small companies should use the Legacy Internet to "reinvent the net". The large companies will never do this because it is not in their best interest and they move very slowly. This type of innovation must come from individuals and small companies. Individuals and small companies can take advantage of the facilities provided by the large providers without directly involving the large providers in this new OuterInternet. Any time wasted trying to work with the large companies is just that...time wasted. In order to build the new OuterInternet, I suggest that small "trusteeships" of 8 people or companies form to work together as a unit. I suggest that the resources (TLDs, IP numbers, etc.) of the OuterInternet be delegated to these trusteeships which can act as natural peer groups. In some cases, a second tier of 8 trusteeships would yield clusters of 64 people/companies which will also provide peer group support. If such trusteeships are formed and advertised, then large companies might begin to take note of the opinions and developments produced by these groups. In some cases, a collection of trusteeships could represent a formidle force when dealing with large companies. Just as the Internet was formed from small collections of individuals and companies experimenting with ideas and implementations, this new OuterInternet can be built using the same model but much more quickly because of the infrastructure provided by the Legacy Internet. In my opion, all of the individuals, small companies and groups that are interested in building the OuterInternet should join a trusteeship and start making a positive contribution to the new system. Maybe the sum total of these trusteeships will someday get the attention of the large carriers but in the meantime that does not need to be the objective. Instead, there are brave new worlds and frontiers to discover and pioneer just like the early Internet explorers. The number 8 has been chosen as an arbitrary size. It is not very large and it is not small. It is smaller than the number of people required to have a baseball team. It is greater than the number of people required in a basketball team. Besides being a power of two, it has the interesting feature that 2 of the people can play primary and secondary roles and each of those 2 can have 2 and those 2 can have 2. This provides for some continuity and the development of people without requiring that everyone be a peer from the beginning. Trusteeships could easily be formed by 1 or 2 individuals developing a web page that advertises for 6 additional players. Resumes could be submitted and the trusteeship would develop a mission and organization to suit the members. A trusteeship name could be chosen and the group could work together to help develop opinions, policies, specifications, software, etc. that are posted as the output of the trusteeship. In the trusteeship systems that I propose, I suggest that the trusteeships be considered to be "peers" and not individuals. The Internet seems to be populated with individuals that only want to peer with other individuals that they feel are worthy. This lack of cooperation and lack of development of "new blood", causes the progress of the Internet to be slow and plays into the hands of large companies. I always find it interesting that people on the Internet with tons of experience only want to talk to people with more experience than them. In some cases, that is a very small number of people. In the trusteeship system, this same sort of social engineering may take place, but there is more of a chance that new people will find a group to join and will not be berated that they are too new to contribute. Anyone that is interested in the trusteeship approach to "peer" groups as opposed to individual peers, feel free to drop me a line. For those people that want to continue to search for someone worthy to be their peer, I wish you luck. Keep in mind, it is lonely at the top. -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming(a)unety.net

1 0