- Test - lists.nanog.org

Re: Policy Statement on Address Space Allocations
by asp＠uunet.uu.net 31 Jan '96

31 Jan '96

> I think that we solved that problem by providing full information for > all of the routes to routers within the area, and none outside. > If you wish to correct me, feel free. So everyone w/in the area can get to all of these sites (& since they have to carry full routes, they don't save any routing table space), and everyone outside of this area has no routes to any part of the area and thus can't get to any of these sites at all? Humm; if I understand you corretly, this seems to be a loose all around. --asp(a)uunet.uu.net (Andrew Partan)

6 10

RE: MCI to market MSN
by Hank Nussbacher 31 Jan '96

31 Jan '96

On Tue, 30 Jan 1996 20:01:36 -0800 (PST) alexy(a)alpha.c2.org wrote: >MCI and Microsoft will now be building networks together, MCI ditching >Netscape and starting to sell Microsoft network access tools & pushing >MSN... > >>From the local rag news paper: > >"MCI, Microsoft to jointly market on-line services > > WASHINGTON -- MCI Communications Corp., switching its Internet Strategy, >said it will team up with Microsoft Corp. to jointly market and develop >services for the burgeoning on-line industry" > >The story later goes on to say: > >"MCI will promote Microsoft Network, the No. 4 U.S. on-line service, and >sell Microsoft's Internet software through its SHL Systemhouse unit" > >Interesting, No? How does this affect UUnet (who provides Internet infrastructure for MSN) and MCI? > >-alex > ---------------------------------------------------------------------- Hank Nussbacher Manager, Internet Technology Programs Telephone: +972 3 6978852 Vnet: HANK at TELVM1 Fax: +972 3 6978115 Internet: hank(a)ibm.net.il ---------------------------------------------------------------------- IBM Israel 2, Weizmann St. Tel Aviv 61336 ====== ======= === === http://www.ibm.net.il/ ====== ======== ==== ==== Dialup registration: 177-022-3993 == == == ==== ==== Company services: 03-6978663 == ====== == === == Internet sales fax: 03-6978115 == == === == = == Enquiries: info(a)ibm.net.il ====== ======== === === Technical support: noc(a)ibm.net.il ====== ======= === === ----------------------------------------------------------------------

1 0

Re: Policy Statement on Address Space Allocations
by Robert A. Rosenberg 31 Jan '96

31 Jan '96

At 5:48 1/30/96, Alex.Bligh wrote: >Thankyou for the first constructive workable suggestion had so far. However, >this has two problems. You're welcome. > >a) RIPE fidn't give me the first /19 in a shorted prefix block > ( its x.x.160.x and .192.x is used), but no matter, I'll renumber > if necessary :-( or persuade them to give me a /18 as well so I > can do the above (hopefully). My convert the /19 to an /18 was a way to get minimal extra announcements. Getting a new /19 and keeping the first 3 /21s for your own use and giving them the 4th, still adds only one EXTRA announcement (over the need to announce the [new] /19 itself). >b) The /21 advert may be inbound filtered by a.n.other, which will be > fine if it has an AS-Path through me (as the less specific route > will work the same way) but won't when that path goes through the > other provider with whom they are multi-homed, as the /21 will disappear > entirely (3rd parties, i.e. a.n.other's customers will see neither), > the /19 will be the only thing that is visible, and I'll just black > hole their packets. As a Multi-Home (as opposed to a Private) /21 it should (theoretically) be entitled to being added to the filter lists as valid - Getting this done is a political problem. You should not be black holing the packets since your receipt of them is VALID (since they are Multi-Homed as opposed to having walked with the block).

1 0

Re: Policy Statement on Address Space Allocations
by Robert A. Rosenberg 31 Jan '96

31 Jan '96

At 11:39 1/30/96, Iljitsch van Beijnum wrote: >> At 6:09 1/29/96, Alex.Bligh wrote: > >> > Currently I have 2 choices as >> >far as I can make out, give them a bit of my /19, break up my >> >nice aggregate and ensure loads of extra announcements (and that >> >probably none of them get routed by anyone applying prefix based >> >filtering), or give them a new /19 all of their own (you've > >Suppose you have a customer that needs a /22 and they want to go >multi-homed. Suppose you give them that /22 out of your /19 or /16 you >got from the RIPE NCC. So they announce their /22 to you and to their >other provider. But you keep announcing your /19 or /16. So if anybody >were to filter the /22 announcement, your customer only suffers partial >loss of connectivity, since you are still announcing an aggregate of >their announcemnt (your original /19 or /16). > >Problem fixed. Anything else? ;-) Unless you announce both the /16 (or 19) AND the /22, they are not multi-homed but only single routed (with some fallback for those who see the /22 announcement). Anyone who gets the unfiltered /22 announcement will used the other provider (so long as that provider is up) while you get used only by those who get a filter routing (and as fallback when the other provider goes down).

1 0

Re: misinformation and rumors from MCI
by matthew＠scruz.net 31 Jan '96

31 Jan '96

Original message <199601310545.XAA14185(a)westie.gi.net> From: Alan Hannan <alan(a)gi.net> Date: Jan 30, 23:45 Subject: Re: misinformation and rumors from MCI > > > Matthem, > > I read your letter with a bit of a frown. ... > Please, in the future, send this mail to the person's manager, not > to the NANOG mail list. People make mistakes, obviously he made > one, and I don't see any reason to drag them/him through the > coals. We've seen this same sort of misinformation propogated by people at the major NSPs for some time now,... the people who know what interconnects really are and what routing policy really is read this list, and their understanding of the technology is presumably well-respected in their organization. If the major NSPs really want small providers to stay around to handle the end-user sales, they're going to have to adopt that attitude comapny-wide, and perhaps the technical people could write up an FAQ or two for their sales staff so that misinformation like this doesn't repeatedly end up in my mailbox, coming from customers who think that WE'RE the ones who lied. This was just yet another "I heard this about you from MCI and they must know what they're talking about" and I thought it might be informative for the readers of this list to see what's being said out there. There's a difference between a mistake and a corporate attitude of "drag all the small guys through the mud by claiming that their connectivity sucks by waving around technical terms". And sure, if nobody else thought this was interesting, I'll be sure to not mention this sort of thing on this list again... no need to waste everyone's valuable mail reading time :) -matthew kaufman matthew(a)scruz.net

1 0

Subscribe
by R. S. Ashton 31 Jan '96

31 Jan '96

subscribe tac(a)acnet.net

2 1

Re: Policy Statement on Address Space Allocations
by Vadim Antonov 31 Jan '96

31 Jan '96

The zero-settlement scheme works ok as long as interconnected parties are of about the same size. That makes them suffer equally from routing bloat. Incidentally, that was part of the reasoning after Sprint's IXP peering policy. In any case having zillions of small ISPs to be at top-level IXPs is economical and technical insanity, and it seems that it can only be fixed by rather steep settlements at IXPs to make it a very expensive prestige shopping. BTW, "settlements for routes" is a rather interesting thing. Imagine, say, Sprint peering with Joe Blow Internet-And-Burgers. Let's assume that route costs $100/yr, so Sprint pays $1M/yr to JBIB and JBIB pays back $300/yr. Sounds like a good business for JBIB :) The better idea is auctioning and trading the routing slots, though it is unclear where the proceeds from the initial auction should go. Probably to fund the Network Police which would chase the bootleg route injectors. I don't know what you make of it, but i think that sucks a lot more than the zero-sum model we have now. --vadim Not speaking for Sprint. PS Given the choice between fixing the technology and fixing the society it is always more prudent to go after technology. >From list-admin(a)merit.edu Tue Jan 30 20:56:10 1996 Received: from merit.edu (merit.edu [35.1.1.42]) by titan.sprintlink.net (8.6.9/8.6.9) with ESMTP id UAA11534 for <avg(a)titan.sprintlink.net>; Tue, 30 Jan 1996 20:56:08 -0500 Received: from nico.aarnet.edu.au (nico.aarnet.edu.au [139.130.204.16]) by merit.edu (8.7.3/merit-2.0) with SMTP id TAA25560 for <nanog(a)merit.edu>; Tue, 30 Jan 1996 19:59:35 -0500 (EST) Received: (from gih@localhost) by nico.aarnet.edu.au (8.6.10/8.6.10) id LAA25214; Wed, 31 Jan 1996 11:56:53 +1100 From: Geoff Huston <G.Huston(a)aarnet.edu.au> Message-Id: <199601310056.LAA25214(a)nico.aarnet.edu.au> Subject: Re: Policy Statement on Address Space Allocations To: huddle(a)mci.net (Scott Huddle) Date: Wed, 31 Jan 1996 11:56:53 +1100 (EST) Cc: asp(a)uunet.uu.net, G.Huston(a)aarnet.edu.au, cidrd(a)iepg.org, nanog(a)merit.edu In-Reply-To: <199601310009.TAA06568(a)new6.Reston.mci.net> from "Scott Huddle" at Jan 30, 96 07:09:12 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R Yes this inevitably leads to another instantiation of the Grande Olde Religious War on Settlements. However now the folk who are religiously tainted towards supporting the continued viability (or even absolute necessity in some versions of the War) of zero dollar interconnection now have the added hurdle of demonstrating how they can also solve the routing table scaling issues as a basic precursor of demonstrating that Zero Dollar settlements (aka free transit) is a Good Thing. Good luck and may the force be with them. And the forum in which this will happen? Personally I'm of the view this is not an area which naturally lends itself to the open processes of NANOG and the IETF. The most likely scenario is that the forum will either be smoke-filled back rooms or elevated views on the 150th floor, or both. And no, this is not a completely comforting answer for many. thanks, Geoff > > In the same way that giving away IP addresses and giving away IP > > routing can only be described as a very bad case of irrational > > behaviour, especially when the underlying resource is under stress as > > it is at present, then I'd also note that giving away transit is > > similarly a case completely irrational behaviour! > > Agreed, but doesn't this lead to the religious War On Settlements. Yakov's > push/pull paper on route announcements coupled with traffic levies > would seem to to address your point. Do you agree? > > > All this points to a desperate need for a more realistic economic > > structure to be used within a number of key aspects of Internet > > infrastructure. > > Agreed, what are the forums, though? There are both techie questions to > be answered as well as hard business case scenarios. NANOG seem > unlikely to address the former, where the IETF seems ill equipped to > answer the latter. > > -scott > > [...] > > Andrew's comments: > > > > > > > > > Half correct. Everyone in the area carries full routes for the block. > > > > Everyone outside the area can listen to only the /8 advertisement. > > > > > > So these providers are providing the free transit to their > > > non-customers? > > > > > > This does not make any business sense; it will not happen. > > > --asp(a)uunet.uu.net (Andrew Partan) > > > > > > > > > > > >

1 0

Re: Policy Statement on Address Space Allocations
by Robert A. Rosenberg 31 Jan '96

31 Jan '96

At 6:09 1/29/96, Alex.Bligh wrote: > Currently I have 2 choices as >far as I can make out, give them a bit of my /19, break up my >nice aggregate and ensure loads of extra announcements (and that >probably none of them get routed by anyone applying prefix based >filtering), or give them a new /19 all of their own (you've >said it, that's the minimum size allocation) which actually >solves their problem and mine, but this isn't an option >currently available because currently it's one window per local-IR. >So they have to go and become a local IR. If the high /21 of your /19 is not Allocated, you just assign it to them and add ONE announcement of the /21 to supersede with the current /19. If it is not free but is sparsely populated you can move the stuff out to free it up or go to RIPE to get your /19 turned into an /18 (ie: get the /19 right after your current /19 [RIPE did give you the first /19 in a shorter prefix block didn't they?]) in exchange for returning the /21 worth of space [giving you 3 extra /21s worth of space], and divide that 2nd /19 into a /20, and 2 /21s giving them the 2nd /21 (still doing the same 2 announcements as you would if allocated out of your current /19).

5 4

Re: Policy Statement on Address Space Allocations
by Scott Huddle 31 Jan '96

31 Jan '96

Geoff Huston <G.Huston(a)aarnet.edu.au> writes > If you manage to provide a better model for interconnection which > includes a rational economic model of interaction then, strangely > enough, you then have a powerful tool you can use to address teh > technical issue of scaling the routing domain. > > i.e. > > "free transit" is stupid, as Andrew indicates. > > "transit" is possible given a rational economic model of the > transit interaction. > > In the same way that giving away IP addresses and giving away IP > routing can only be described as a very bad case of irrational > behaviour, especially when the underlying resource is under stress as > it is at present, then I'd also note that giving away transit is > similarly a case completely irrational behaviour! Agreed, but doesn't this lead to the religious War On Settlements. Yakov's push/pull paper on route announcements coupled with traffic levies would seem to to address your point. Do you agree? > All this points to a desperate need for a more realistic economic > structure to be used within a number of key aspects of Internet > infrastructure. Agreed, what are the forums, though? There are both techie questions to be answered as well as hard business case scenarios. NANOG seem unlikely to address the former, where the IETF seems ill equipped to answer the latter. -scott [...] > Andrew's comments: > > > > > > Half correct. Everyone in the area carries full routes for the block. > > > Everyone outside the area can listen to only the /8 advertisement. > > > > So these providers are providing the free transit to their > > non-customers? > > > > This does not make any business sense; it will not happen. > > --asp(a)uunet.uu.net (Andrew Partan) > > > > > >

2 1

Re: Policy Statement on Address Space Allocations
by Brett D. Watson 31 Jan '96

31 Jan '96

> > > > Ah, the "Bill Manning Solution"(tm). Now if we could only get ISPs > > like Sprint to play, Bill could get his Nobel Internet Prize. > > > > Er, this is to give you notice that my legal counsel advises me > that you should cease and desist until the appropriate documents > are signed. > > And its not the Noble (or even igNobel) prize I'm after, its > 192.0.0.0/8 !!!! Bwahahahah :) > > As to the monies collected? I need a new wardrobe and a shave. > Perhaps even a life :) at least buy some new t-shirts :) -brett

1 0