- NANOG - lists.nanog.org

Re: standards for giving out blocks of IP addresses
by Charles Scott 18 Jun '01

18 Jun '01

On Sat, 16 Jun 2001, David R Huberman wrote: > Either you're saying it wrong (writing it wrong, as it were) or you are > misunderstanding RFC2050. > > ISPs *should* request 80% utilization of a block assigned to an end-user > prior to assigning additional address space. > > You understand that, right? On Sat, 16 Jun 2001 up(a)3.am wrote: > It's not really a question of what makes sense, it's what you need to do > to keep ARIN happy. As an ISP, if you only apply the 25% / 50% rule to > your customers, how are you supposed to demonstrate 80% utilization to > ARIN when requesting any kind of allocation? > > If you've handed out a whole bunch of /24 - /29 subnets to your > customers and they are compliant with RFC2050, this could well result > in a situation where you've depleted nearly all of your address space, > yet are nowhere near 80% utilization or your, say, /21 from your > upstream. Is ARIN going to allocate you a /20? David: Sorry, but nope, I don't understand it that way. Perhaps we need to properly define utilization. To an ISP, this means assignment of address space via SWIP to customers. ARIN wants you to have "assigned" 80% of your address space before asking for another allocation. To an end user, it means active hosts. ARIN suggests following RFC2050 and the 25%/50% standard prior to receiving an additional address assignment from their ISP. You, the ISP, are obligated to have justification using RFC2050 as the standard for assignements to your customers. ARIN requires you to have assigned 80% of your allocation to those customers prior to receiving additional allocations and may want to review the justification you've received from your customers. So, yes, it's very likely that when you have assigned 80% of your allocation, the sum of all your customer's utilization may be something like 50%. Judging from the confusion on this issue, I'm not surprised that some customers have a hard time getting assignments from their ISP's. This is even more confusing when the customer is both an end user and a downstream ISP themselves. In that case, it may make sence to consider the address space they use themselves as a separate assignment from them to themselves. That way you can properly determine when they have reached 80% assgnment of their space. If they aren't in turn assigning address space, then they are simply an end user and should be following RFC2050. Does this all make sence? Chuck

3 11

Re: standards for giving out blocks of IP addresses
by Charles Scott 17 Jun '01

17 Jun '01

Joshua: So what you're saying is that if I want to find out what the policy is, that I shouldn't bother going to the RIR's web site for any guidance. And, should I do that and actually bother to read the information they supply, I should ignore it because it doesn't mean anything since all that counts is what the "insider" of the day says it should be. And, if they refer to an RFC (yes I know what that stands for) then I shouldn't bother to look it up and read it, because it's only a suggestion and, "we don't really do things that way anyway". With all due respect, it's exactly that kind of situation that causes problems. Now I think I understand...somehow it's all starting to make sence. Chuck On Sun, 17 Jun 2001, Joshua Goodall wrote: > > On Sat, 16 Jun 2001, Charles Scott wrote: > > > On Sat, 16 Jun 2001, David R Huberman wrote: > > > > > - Both are judged to have used their existing assignment 'efficiently' if > > > they have used 80% of it. > > > > Nope. But I give up. > > As a multiple LIR operator and one-time RIR insider, I can say that david > is correct with regard to policy in practise, and *that* is what matters. > > 2050 does not address issues relevant to a hierarchy of IRs and for this > (and other, more human) is only useful as a historical base for > understanding RIR policy. > > Beware the RFC lawyers who've forgotten what the letters "RFC" stand for. > > J

2 2

RE: standards for giving out blocks of IP addresses
by Martin, Christian 16 Jun '01

16 Jun '01

> Of course bandwidth != subnet mask. He should give them > whatever IP's > they demonstrate a need for in the next three months. Determining and > justifying that > need has nothing to do with how over (or under) subscribed their > bandwidth is. Let us not forget what some salespersons will promise to potential large bandwidth customers. An OC-3 POS customer, for example, can expect many many /24s. One may say "They should go to ARIN", but alas, they would have to pay another $2500 on top of the $1 million+ they are paying for transit. <8{} It is surprising how much a salesperson will "sell" to get the commission on a 5 year OC-3 contract, forget about OC-12/48... So, in some cases, like it or not, bandwidth sold is proportional to IP addresses. chris > > If they are in fact only selling dialup (not leased lines, not web > hosting), > you might ask how many pops(locations) they plan to have right away, > modems/pop, space > reserved for internal devices (email/corporate lan) and links. You > could > easially justify a couple of /24's with a couple locations > and IP's for > all the new PC's in the marketing dept. > > KL >

5 6

The Cidr Report
by Tony Bates 16 Jun '01

16 Jun '01

This is an auto-generated mail on Fri Jun 15 23:00:00 PDT 2001 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to GX Networks for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 15Jun01 0) General Status Table History ------------- Date Prefixes 080601 102522 090601 102942 100601 102382 110601 102484 120601 102300 130601 102055 140601 101900 150601 101429 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 6880 Number of ASes announcing only one prefix: 2796 (0 cidr, 2796 classful) Largest number of cidr routes: 0 announced by Largest number of classful routes: 1403 announced by AS701 1) Gains by aggregating at the origin AS level --- 15Jun01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1392 1032 360 25.9% UNKNOWN AS701 1403 1217 186 13.3% UNKNOWN AS4293 396 281 115 29.0% UNKNOWN AS4151 252 137 115 45.6% UNKNOWN AS4755 256 142 114 44.5% UNKNOWN AS6429 207 102 105 50.7% UNKNOWN AS6595 159 59 100 62.9% UNKNOWN AS705 251 155 96 38.2% UNKNOWN AS13999 103 11 92 89.3% UNKNOWN AS8013 300 222 78 26.0% UNKNOWN AS577 254 179 75 29.5% UNKNOWN AS7018 700 628 72 10.3% UNKNOWN AS724 223 159 64 28.7% UNKNOWN AS6471 114 50 64 56.1% UNKNOWN AS3464 152 90 62 40.8% UNKNOWN AS1 597 538 59 9.9% UNKNOWN AS16758 63 6 57 90.5% UNKNOWN AS2149 333 277 56 16.8% UNKNOWN AS1239 439 384 55 12.5% UNKNOWN AS3908 207 154 53 25.6% UNKNOWN AS226 143 90 53 37.1% UNKNOWN AS6413 66 14 52 78.8% UNKNOWN AS5106 95 43 52 54.7% UNKNOWN AS17561 112 61 51 45.5% UNKNOWN AS3602 229 179 50 21.8% UNKNOWN AS13544 69 19 50 72.5% UNKNOWN AS9842 54 5 49 90.7% UNKNOWN AS852 209 160 49 23.4% UNKNOWN AS855 144 98 46 31.9% UNKNOWN AS3749 94 48 46 48.9% UNKNOWN For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

Multicast Traffic on Backbones
by Deepak Jain 16 Jun '01

16 Jun '01

Don't know why I came across this, but I found a document on Sprintlink's site that says their entire backbone is multicast enabled, and they also peer with the MBONE for multicast traffic. They charge no fee for dedicated customers to be multicast-enabled. Are any other major networks doing this? Or have I been living under a rock and _everyone_ is doing this now? Thanks, Deepak Jain AiNET

20 37

Frame-Relay vs. ATM?
by Los, Ralph 15 Jun '01

15 Jun '01

Hello everyone, I apologize for putting this out to everyone, but I don't know the answer to this question and I feel it's best to go to the source. My company is forcing me to do a Frame vs. ATM cost-benefit comparison. The Frame-Relay connection would be PVC's connecting 3 sites, Chicago, West-Coast, East-cost (offices). I am attempting to do video-on-demand, voice-over-IP, and data over these pipes, and would like to ability to do Internet+private LAN connecting all 3 sites for file-sharing, email sharing, etc without having to do VPN over the Internet. My question? What is the benefit of Frame-Relay from say, Sprint or AT&T versus an ATM connection for all 3 sites from Savvis or Broadwing? I'm trying to find the technical details and merits behind both these methods/technologies. Any replies would be appreciated off-list, and I will send a aggregate report to anyone interested. Thank you much everyone for answers in advance, Ralph M. Los Asst. Vice-President, Internet Systems and Security EnvestNet Advisory Corp. rlos(a)envestnet.com (312) 827-3945 (direct) (312) 296-9003 (wireless w/voicemail)

1 0

cogentco.com technical analysis?
by Murphy, Brennan 15 Jun '01

15 Jun '01

I was wondering if anyone had any experience with Cogent Inc. They are one of the companies offering high speed internet (fast ethernet/GigE) at rock bottom prices. :-) I know the adage "you get what you pay for" typically applies but I was looking for some concrete end user experiences. I'm not trying to break the charter of this mailing list by devoting a discussion to various emotion based opinions about a particular vendor. I am actually seeking technical opinions on whether what is being advertised is actually being delivered with reliability. More specific questions: do Cogent's peering arrangements seem adequate to the amount of bandwidth they are offering? Or are these major bottlenecks to an otherwise good network? Are any of Cogent's competitors worth taking a look at? Any non-obvious reason why? Does anyone have any statistics to provide that paints a picture about what you get from their products? I guess if enough people complained that this was too off topic, I could still request direct replies and I could put a summary together for any interested parties. But I reread the charter before putting this together and it seems fair game. When is Worldcom, et al going to start offering these products? ( maybe when companies like cogent start succeeding?) Thanks, -BM

10 13

RE: Mae-East FDDI funeral
by Hire, Ejay 15 Jun '01

15 Jun '01

>P.S. Mae-East FDDI officially gets turned off tomorrow (June 15th) according >to the most recent update I've seen. Anybody know if they are going to be doing equipment disposal? I'd love to add FDDI to my home not-for-commercial-or-profitable-use-please-let-the-gods-of-networking-smile -on-me lab. I have a truck, and will haul. (and I'm not completely above dumpster diving either!) -Ejay

1 0

Re: Multicast Traffic on Backbones
by Thomas R. Charron 15 Jun '01

15 Jun '01

>Essentially every major network operator has one network engineer >who can set up multicast for customers. The problem is very few >networks have figured out how to turn multicast into a commercial >product. So if you don't find that one engineer, you are out of >luck. >Unicast streaming may be less efficient, but most providers can figure >out how to charge for it and make it a supported product. Unfortunately >some folks have confused multimedia with multicast. While I've seen >many multimedia multicast applications, I haven't seen one which can't >have its essential elements replicated by unicast streams. Is there >a killer-ap for multicast? A South Korean company has developed an app that sets up multicast on a network automatically. No router config required. It does it with a small active-x that installs on a user's machine and gives a server on the ntwk all the info it needs to route the multicast stream. Pretty cool stuff. I'd call it a killer-ap for multicasting. Tom

2 1

RE: Multicast Traffic on Backbones
by Thomas R. Charron 15 Jun '01

15 Jun '01

"Thomas R. Charron" <tomc(a)koreawisenut.com> writes: > A South Korean company has developed an app that sets up multicast on a > network automatically. No router config required. It does it with a small > active-x that installs on a user's machine and gives a server on the ntwk > all the info it needs to route the multicast stream. Pretty cool stuff. > I'd call it a killer-ap for multicasting. It sounds as if I'd probably call it "unicast". ---Rob No, it's multicasting. The active-x interacts with the server to determine which clients are viable for grouping into a virtual multicasting ntwk (independently of routers). These little active-x's interact with the server to register themselves in a multicast group, and they can repeat the signal for others in their group or even to other groups. It's P2P and IP Multicasting put together. Tom

1 0