- Test - lists.nanog.org

MAI Announces Detroit MXP
by Justin W. Newton 26 Jan '96

26 Jan '96

MAI, Network Services announced today that the Detroit MXP (Metropolitan Exchange Point) is ready for operation. Parties interested in connecting to the MXP should contact Justin Newton (justin(a)mai.net) or Vincent Bono (vbono(a)mai.net) at (703) 506-0505. More information can be found on the Detroit MXP web page at: http://www.mai.net/mxp/detroit/mxp.htm. Justin Newton | jnewton(a)hq.mainet.com Internet Administrator # (703) 506-0505 MAI Network Services | Detroit MXP online soon #

1 0

Re: Policy Statement on Address Space Allocations
by Sean Doran 26 Jan '96

26 Jan '96

Dennis said: >>[192 et al] look like swamps that are ripe for the picking. Bill said: >Already underway as part of PIER Yay. I'm looking forward to the updates. I'm even more looking forward to technology that makes renumbering tractable, because that will end this entire line of discussion pretty much forever. Sean.

1 0

Re: Policy Statement on Address Space Allocations
by Ronald Khoo 26 Jan '96

26 Jan '96

You're trying to achieve a perfect policy that will work for all time when what we need is something to eke out IPv4 for the rest of its natural life. By the time enough of your postulated ISPs have grown big enough AND THEN shrunk enough for this to matter in any practical sense, IPv4 will have become mostly static, and all of us here will have retired from active Internet Politics. I hope. On Jan 26, 12:59pm, Daniel Karrenberg wrote: } Subject: Policy Statement on Address Space Allocations } } > Ronald Khoo <ronald(a)office.demon.net> writes: } } > Here's a suggestion for one simple rule. "Where delegating address space } > to a provider registry, a) never delegate a block smaller than any } > existing PA block already delegated, and b) once 3 such blocks are } > delegated, always delegate a block at least 4 times bigger". } } While sounding fine in general, this assumes ever increasing growth } of ISPs. An assumption easily proven invalid by counterexample. } } Daniel }-- End of excerpt from Daniel Karrenberg -- Ronald Khoo <ronald(a)demon.net> +44-181-371-1000 FAX +44-181-371-3750

2 1

Re: Policy Statement on Address Space Allocations
by hwb＠upeksa.sdsc.edu 26 Jan '96

26 Jan '96

>IANA is the *Naming and Addressing* Authority. But to the >best of my knowledge the IANA's authority is not sufficient to >guarantee Internet-wide connectivity. There is no authority any more. May have been in the ARPAnet, *may* be in the NSFNET days. The IANA/InterNIC thing is essentially a coordination function that assumes that everyone plays and in result gives a good probability of global uniqueness in varieties of assignments. If the policies are not being accepted, the non-accepters will weight global interconnectivity against needing to provide services in a perhaps isolated environment. Many will choose global connectivity, some others may not. Example. A few weeks back or so I needed an AS number, but the InterNIC came back, after I filled out their form, with what I considered unreasonable additional requests, and I thought screw it, I don't need this, I just pick a number. The setup was semi-experimenal anyway (some routing research, but connected), and if someone complains I can fix it later, or send them after the InterNIC. So, the coordination function has failed there, and there was certainly no authority involved. I liked Dennis' note about picking reasonable targets, btw, and going for those somehow, may be doing "limits by declaration," so we find out what's reasonable, rather than dwelling in doom or no-doom about address spaces and so. That something that could be done at the NANOG meeting, with some email in advance and after?

1 0

Re: Policy Statement on Address Space Allocations
by Jeff Young 26 Jan '96

26 Jan '96

>It's the other way round: SPRINT should tell his customers he can't >guarantee 100% global Internet connectivity because he disagrees with >the current address allocation policy of the IANA/InterNIC/RIPE NCC/AP-NIC. >They might want to look for a different transit provider... > >Regards, > >Miguel say what you will about this policy, but someone (sean?) thought long and hard about it's implications. i didn't like the abrupt manner in which it was implemented, but it does take guts and it is pretty elegant: it's everyone else's 206 customers who can't reach sprint's customers. even though it's the packets from sprint's customer's that can't make it back to everyone else. that's the beauty of it. sprint announces networks in the 206 space to us and to everyone else. we accept the announcements if they are larger than /24: *> 206.12.94.0 192.41.177.241 128 80 0 1239 3602 ? *> 206.12.187.0 192.41.177.241 128 80 0 1239 1794 ? *> 206.13.159.0 192.41.177.241 128 80 0 1239 1791 3064 i * 206.24.100.0/23 192.41.177.241 128 80 0 1239 1792 3563 i *> 206.40.99.0 192.41.177.241 128 80 0 1239 3663 i *> 206.40.100.0 192.41.177.241 128 80 0 1239 3663 i *> 206.40.101.0 192.41.177.241 128 80 0 1239 3663 i *> 206.40.102.0 192.41.177.241 128 80 0 1239 3663 i *> 206.40.103.0 192.41.177.241 128 80 0 1239 3663 i * 206.40.128.0/19 192.41.177.241 128 80 0 1239 4534 i so if i'm a customer of sprint in a 206+ network that is announced as a /24, i have a route to the world. the real message is if you have a 206+ address, make sure that your provider can put it into an aggregation block for you (or go to sprint). nobody said it would be boring. :-) Jeff Young young(a)mci.net

1 0

Re: Policy Statement on Address Space Allocations
by Scott Bradner 26 Jan '96

26 Jan '96

> I think the hierarchical routeing is one step *worse* than the above. > The address *defines* the route the packets take ? What about the real, > live multi-interconnect, multi-homed Internet we use ? Maybe I have > misunderstood the way IPv6 addressing works. HR sure does sound real bad, just for grins what is your plan to keep the routing table size within the constraints of the routers without it? Scott

1 0

Re: Policy Statement on Address Space Allocations
by Sean Doran 26 Jan '96

26 Jan '96

Jeff Young wrote: | say what you will about this policy, but someone (sean?) thought | long and hard about it's implications. i didn't like the abrupt | manner in which it was implemented, but it does take guts and it | is pretty elegant: Thanks, Jeff. Once again I shall repeat my apologies -- the original intent was to make sure the filters would break things on day one, rather than retroactively apply to the number of people whose route announcements had been leaked in by mistake. Despite the immediate retrospective thought that it was a cute way to avoid accusations of collusion among big providers, I did very much regret the work you folks and others had to do when this got dropped into place. OTOH, well, there had been several months' warning about the details... But still, sorry that it wasn't as smooth as it could have been if there hadn't been a flaw in the filtering that crept in in about April, long before anyone was even really thinking of allocating from 206.0.0.0/8. However, as I think everyone remembers, after a short while, in an effort to assist in getting aggregation of the then-announced bits of 206.0.0.0/8 working OK and giving people some time to get used to the filtering, I did relax the filtering on 206.0.0.0/8 to permit /19s. As you note, this was to the benefit of other peoples' customers. | the real message is if you have a 206+ address, make sure that your | provider can put it into an aggregation block for you (or go to sprint). Right, and we have been warning our customer base for some time that if they announce a 206+ address that is not aggregatable into something reasonably big (like a /18), they run the risk of losing connectivity to other providers if they ever were to impose similar filters for business or technical reasons. Meanwhile, yes, it's a slight competitive advantage. :-) (Frankly though, that was a at first side-effect of not having the ability to do the outbound filtering immediately, but it rapidly seemed like a smart thing to do to make other people think about similar filtering. An interesting thing to wonder about is how different the early days of CIDR deployment would have been if rather than aggregating at the source, people were to have set up some sort of inbound filtering at places like MAE-EAST.) | nobody said it would be boring. :-) Yup. Sean.

1 0

Re: Policy Statement on Address Space Allocations
by Peter Galbavy 26 Jan '96

26 Jan '96

> Despite the weather forecast, I'm sure you'll warm to RIPE, its > members and even its "bureaucracy", and perhaps revise your > opinion in the light of an enjoyable experience. > > Looking forward to meeting you in Amsterdam. Me too. See you all there... -- Peter Galbavy peter(a)demon.net @ Demon Internet phone://44/181/371_3700 http://www.wonderland.org/~peter/ snail://UK/N3_1TT/London/42_Hendon_Lane/Demon_Internet_Ltd/

1 0

Re: Policy Statement on Address Space Allocations
by Sean Doran 26 Jan '96

26 Jan '96

Paul - Thank you for your kind words. Sprint's filtering policies have led directly to a more survivable SprintLink and ICM, which is to the benefit of Sprint's Internet customers. The trade-off is the inability to reach people who have just hooked up to other parts of the Internet for the first time and who are using addresses that are in conflict with what we feel our routers can support. So far the two (yes, two) customer-originated complaints involving reachability affected by our filtering have been resolved by straightforward renumbering of the non-SprintLink entity. There have, by comparison, been several hundred rather angry messages from non-customers who hook up and find that they can't use their freshly-acquired addresses to talk to SprintLink/ICM, and who claim never to have been warned that this was a virtual certainty. Two troubles in several months are rather obviously dwarfed by the thousands of customer-originated complaints about routing problems after major exchange points or other major routing transitions happen (we have observed major peers having serious difficulties with their routing system scaling recently), not to mention the most recent serious connectivity problem which involved working very closely with our vendor on getting new technology out the door that will let us scale with increasing traffic and hopefully better deal with the scaling of the increase of globally-announced routing informaiton. Customer feedback I have gotten about our CIDR and other routing policies tends to be very positive. Indeed, a number of our customers are active participants in CIDRD, NANOG, EOF and other forums where these policies sometimes are discussed at length, and none of them seem very shy about putting forward their own points-of-view, all of which is remembered and thought about frequently. We are, after all, very keen as a corporation to develop and maintain long-lasting relationships with our customers. It is possible that a number of unhappy customers have not made themselves heard, or that a number have simply voted with their feet on this precise issue, however there certainly has not been enough of the latter to justify any sort of re-think on this particular policy. Whenever I see "Sprint sucks" in newsgroups and mailing-lists, it's almost always because of reliability problems. One of our most serious backbone reliability problems involves routing convergence times and long-term stability, and this particular routing policy in combination with BGP dampening and other tools and techniques we've developed here, goes directly to the heart of those problems. I am always interested in proposals that will help provide a more robust and stable level of connectivity and performance to our entire customer base, and if you have any ideas that would make it reasonable to withdraw our prefix-length filters and _improve_ our routing stability, I would be very glad if you could detail them. Sean.

1 0

Re: value of co-location
by Kent W. England 23 Jan '96

23 Jan '96

At 04:57 PM 1/19/96 -0800, Paul A Vixie wrote: >... The telcos have really screwed the pooch >with ISDN, SMDS, and ATM. I'm not sure why F-R has worked well without >years of delay, but it's a real anomoly. I have little if any confidence >that I will be able to buy OC3 speed ATM and use it to contact 200 >(or even 20) metro-area NAP partners any time this century. > >ISP's who practice conservative engineering (i.e., safe sex) will continue >to buy the fastest telco pipes they can get _among_those_which_actually_work_ >and this is probably going to be raw fibre before it starts to be 155Mb ATM. >I'm not in love with the idea of a barn full of routers all hooked up to >a GIGAswitch milking machine, but I have to prefer the config that works. > Religious arguments aside, the obstacle for TCP/IP performance over ATM has been due to two factors, small buffers and no explicit flow control. The new switches have large buffers. TCP works well with these switches. Explicit flow control will allow more flexible bandwidth management. That applies to TCP as well as ATM. Check out the price of an ATM circuit (considering overhead, etc) and if you perceive value for the BW then buy it. No apology needed, just purchase orders. :-) If you find that you prefer raw bandwidth over optical fiber and lots of cisco interfaces, fine, but if you like network level switching, shared network bandwidth and the price for that, buy switched services. --Kent

9 10