- NANOG - lists.nanog.org

Re: Address "portability"
by Erik-Jan Bos 06 Apr '96

06 Apr '96

Peter, > > What is the general consensus of this group regarding the "portability" of > > addresses in the 204/8 and 205/8 range? > > Portable addresses is an illusion, as it does no scale. > > Give me a call when you convinced the phone_company to make my > phone number work in California. Maybe this is considered poorman's portability, but: When I take my GSM-phone to Hong Kong (or to Stockholm) my grandmother is still able to give me a call while I am there on the same number as when I am at home... Address portability at work... __ Erik-Jan.

3 2

Re: Address "portability"
by Justin W. Newton 06 Apr '96

06 Apr '96

At 12:32 PM 4/5/96 -0800, Matthew Kaufman wrote: >The California PUC has approved local phone competition within California, >with the requirement the phone number portability (between carriers) be >fully implemented as soon as possible. Making your phone number stay the >same no matter whether you're a PacBell or MFS or TCI customer is exactly >the same problem as making IP addresses portable... just wait until ISPs >are regulated, and they get the same mandate. Uhm, Cisco, you hear that? Justin Newton * You have to change just to stay caught up. Internet Architect * Erol's Internet Services *

2 1

RE: 192/8 survey (was Re: NANOG/IEPG/ISOC's current role)
by Jim Fleming 06 Apr '96

06 Apr '96

On Friday, April 05, 1996 7:09 PM, Suzanne Woolf[SMTP:woolf@isi.edu] wrote: @ @As most folks here already know, the basic problem with cleaning up @the TWD, and by extension any chunk of IP space, is in two parts: @ @1. Finding the people responsible <snip> @ @2. "Social engineering" their behavior <snip> @Regarding item 1, we're proceeding with the problem of cleaning up the @contact information we do have. Regarding Item 2, I suspect some, @perhaps many, providers would be willing and able to help with an @educational effort in this area targeted towards their customers; such @an effort needs materials and followup, but seems do-able. @ @ @Suzanne @who still thinks (hopes?) social @engineering doesn't require blunt instruments @ As part of the educational effort you might want to add information about IPng (IPv6) as well as RFC 1918...this may help to give people hope... also, you might want to develop some incentive programs for turning in IP Addresses..."awards", press, etc...along this line I think that there should be some "peer pressure" approaches added to the process... do publicly held companies want to be exposed as "wasting" IP addresses..?? this might be worse than "acid rain" or "water pollution"... -- Jim Fleming UNETY Systems, Inc. Naperville, IL 60563 e-mail: JimFleming(a)unety.net

2 1

RE: 192/8 survey (was Re: NANOG/IEPG/ISOC's current role)
by Paul Ferguson 06 Apr '96

06 Apr '96

At 09:46 PM 4/5/96 -0600, Jim Fleming wrote: > >As part of the educational effort you might want to add information about > IPng (IPv6) as well as RFC 1918...this may help to give people hope... > Please, don't get me started on v6. ;-) - paul

1 0

RE: CIDR,Sprint and the Big Guys.
by salo＠msc.edu 06 Apr '96

06 Apr '96

> Date: Fri, 05 Apr 1996 17:12:24 -0800 > To: salo(a)msc.edu (Tim Salo), nanog(a)merit.edu > From: "Kent W. England" <kwe(a)6SigmaNets.com> > Subject: RE: CIDR,Sprint and the Big Guys. > > At 08:25 AM 4/5/96 -0600, Tim Salo wrote: > >Perhaps, the [anticipated] consolidation of ISPs will be a significant > >event in the efforts to control routing table size. > > > Do we need address leasing to hasten that process or should we let the > market decide? In any event, anyone buying up a bunch of ISPs will have a > difficult time cleaning up the aggregation of addresses they inherit. Obviously, cleaning up the current swamp is difficult. On the other hand, should consolidation occur, presumably a smaller number of larger ISPs would use a smaller number of larger address blocks, (plus or minus issues of the magnitude of dual-homing and changing upstream providers). -tjs

1 0

Re: Address "portability"
by Paul Ferguson 06 Apr '96

06 Apr '96

At 06:39 PM 4/5/96 -0500, Justin W. Newton wrote: >At 12:32 PM 4/5/96 -0800, Matthew Kaufman wrote: > >>The California PUC has approved local phone competition within California, >>with the requirement the phone number portability (between carriers) be >>fully implemented as soon as possible. Making your phone number stay the >>same no matter whether you're a PacBell or MFS or TCI customer is exactly >>the same problem as making IP addresses portable... just wait until ISPs >>are regulated, and they get the same mandate. > >Uhm, Cisco, you hear that? > > Um, and pray tell, what exactly is cisco supposed to do about this? I'll write my congresscritter if you write yours. :-) - paul

2 1

Re: 192/8 survey (was Re: NANOG/IEPG/ISOC's current role)
by Paul Ferguson 06 Apr '96

06 Apr '96

At 05:09 PM 4/5/96 PST, Suzanne Woolf wrote: >In addition, we did some preliminary analysis on routing table entries >for /24s in 192/8, which we presented in the IEPG meeting on March 2, >available as http://www.isi.edu/div7/pier/whose_routes. But the >indications so far are that the required contact information is >scattered and incomplete. Suzanne, This URL appears to be non-existent. :-) - paul

1 0

RE: the Internet Backbone
by Jim Fleming 06 Apr '96

06 Apr '96

On Friday, April 05, 1996 1:55 PM, Paul Ferguson[SMTP:pferguso@cisco.com] wrote: @Better yet, call it the 'default-free core', which is ironically what it @is already called. :-) @ @- paul @ Actually some of the large carriers do have a hidden default route...to the bit bucket...:-) -- Jim Fleming UNETY Systems, Inc. Naperville, IL 60563 e-mail: JimFleming(a)unety.net

1 0

Re: ATM overhead
by Paul Ferguson 06 Apr '96

06 Apr '96

At 05:12 PM 4/5/96 -0800, Kent W. England wrote: > >I have been doing some more arithmetic on the "ATM cell tax" to see if I can >find out how folks get from 10% (which is the 5/53 overhead) to 35% >overhead. I would really really like to see some backup for those sort of >numbers -- I can't make the arithmetic work out to anything near 35% for >what I think are useful assumptions. Of course, if you want to posit 100% >of IP traffic with 49 bytes, but that doesn't seem realistic and you >shouldn't forget that 40 of those are TCP/IP overhead. :-) > >What traffic mix do you use to calculate ATM overhead and what results do >you get? > Trying to avoid reinventing the arithmetic wheel here, I've taken the liberty of cutting-and-pasting a couple of snippets from earlier discussions on this topic. [snip] Date: Tue, 19 Mar 1996 19:51:33 -0800 From: Jim Forster <forster(a)cisco.com> Sender: owner-nanog(a)merit.edu He's talking about the overhead due to carrying variable length IP packets in fixed length ATM cells. Consequently the last cell of an AAL5 frame will contain 0 - 39(?) bytes of padding, which is wasted bandwidth. Assuming random length distributions (which they're not), the average waste is about 20 bytes per packet. My rough estimate, based on an average packet size of 200 bytes (used to be correct, not sure anymore), is that the waste due to cell padding is about 10%. Due to the highly skewed packet size distribution the actual overhead might vary substantially. Note that this 10% is on top of the ~10% overhead due to the 5 byte ATM cell headers (5/53 ~= 10%), and various other overheads (some of which are also present in frame over Sonet schemes). There's beginning to be some expectation that there will be a transmission capacity crunch in the carrier's Sonet nets, and this ~25% ATM cell tax may be looked at carefully as packet over Sonet solutions emerge. [snip] From: Wolfgang Henke <wolfgang(a)whnet.com> Date: Tue, 19 Mar 1996 20:34:05 -0800 (PST) Sender: owner-nanog(a)merit.edu Great. Let's estimate the ATM bandwidth available on an OC-3. With STS-3c SONET at 155.520 Mbps it gets reduced to 149.760 Mbps due to section, line and path SONET overhead. Next we reduce 10% due to 20 bytes lost on average 200 byte long packets due to incomplete ATM cell fills resulting in 134.784 Mbps. Then we need to subtract 9.43% due to ATM headers of 5 bytes in 53 byte packets. Thus we end up with a 122.069 Mbps true information rate which is about 78.5% of the nominal OC-3 capacity. And we still have not raised the issues of wasted reserved bandwidth and routing ease which were recently addressed very eloquently by Vadim Antonov when comparing connection based with packet based transport. [snip] Me again. Finally, these are the various overheads mentioned in Jim's message above: ATM AAL5 8 bytes LLC snap encap 8 bytes unused part of cell 0-40 bytes (avg. 20) --- 36 bytes (avg.) - paul

1 0

Updates, peering & flaps [Was: RE: CIDR,Sprint and the Big Guys.]
by Paul Ferguson 06 Apr '96

06 Apr '96

At 05:12 PM 4/5/96 -0800, Kent W. England wrote: > >BTW, I thought it was the updates, peerings and flaps that was the true >problem, not the absolute number of routing table entries. > > I submit that its a combination of all the above, and that the problem grows in scope as each linearly increase both in size and/or frequency. Of course, route-dampening helps on one front, but its non-trivial to code a smaller routing table when the number of routes increase. :-) - paul

1 0