Re: 69/8...this sucks
--On Tuesday, March 11, 2003 16:47 -0500 Randy Bush [EMAIL PROTECTED] wrote: so let's see how much of a kludge we can make to show how clever we are. How about if we all chip in to hire a bunch of out of work consultants to fly to the NOCs of the various backbones who are being boneheaded to educate them with a clue-by-four? Alec -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
RE: VoIP QOS best practices
--On Monday, February 10, 2003 10:19 -0800 Bill Woodcock [EMAIL PROTECTED] wrote: It works fine on 64k connections, okay on many 9600bps connections. T1 is way more than is necessary. I'd say that largely depends on which codec you are using and how many simultaneous calls you will have going. Alec -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
RE: VoIP QOS best practices
--On Monday, February 10, 2003 13:41 -0500 Charles Youse [EMAIL PROTECTED] wrote: Speaking of codecs, what are the primary variables one uses when choosing a codec? I imagine this is some function of how much bandwidth you want to use versus how much CPU to encode the voice stream. The other dimension is voice quality. Alec -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
Re: Using link congestion to control routing updates
--On Thursday, December 19, 2002 12:10 -0500 David Scott Olverson [EMAIL PROTECTED] wrote: Hello all, I was wondering if anyone was aware of a way to use the congestion of a network link to control the routing update. For example if I have a very small link that gets congested, I may want the router to withhold a routing update until link congestion falls below a certain threshold like 60% of bandwidth. Is anyone aware of anything like this available today or a technique that might accomplish something similar? You can contact me off list if this topic isn't germane. Route flap is bad. Something like this would introduce a huge amount of route flap, and would probably just end up causing congestion ossilation. As far as I know there is nothing to do this in the 'common' routers (cisco, Juniper). Alec -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
RE: FW: /8s and filtering
--On Tuesday, December 10, 2002 13:08 -0600 Ejay Hire [EMAIL PROTECTED] wrote: Having a /24 doesn't indicate you are a network of any particular size, ARIN ratified a policy that allows multihoming as justification for a /24. I am not aware of ARIN taking such action. To which policy are you referring? Alec, ARIN AC member -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
RE: FW: /8s and filtering
--On Tuesday, December 10, 2002 13:08 -0600 Ejay Hire [EMAIL PROTECTED] wrote: Having a /24 doesn't indicate you are a network of any particular size, ARIN ratified a policy that allows multihoming as justification for a /24. I was thinking about PI space. ARIN did in fact ratify a policy stating that a provider may allocate a customer a /24 of PA space if they are multihomed. Alec, red-faced AC member -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
RE: FW: /8s and filtering
--On Tuesday, December 10, 2002 11:41 -0800 Harsha Narayan [EMAIL PROTECTED] wrote: Hello, The policy says that a /24 of PA space can be given if the customer can show that it has an immediate requirement of 25% of the /24 = /26. Policy 2001-2 was ratified recently, which is separate and says that if the customer is multihomed he may receive a /24 with multihoming being the only justification. Alec -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
Re: Operational Issues with 69.0.0.0/8...
--On Monday, December 9, 2002 9:52 + [EMAIL PROTECTED] wrote: Clearly you haven't been following the ppml mailing list. As I have already suggested on that list, ARIN could publish an authoritative directory of all unallocated IP address space at the largest aggregate level in a form that makes it easy for network operators to incorporate into their martian filters. I have been following it quite closely, actually. Why would ARIN specifically provide such a list? ARIN is not responsible for the unallocated space, and there is more in the world than just ARIN. There are liability issues with that, not to mention the fact that it is more an IANA function (if for the sake of argument someone would implement the list). And no, I'm not suggested that anyone connect their productions routers directly to an ARIN BGP feed. Smaller network operators will probably find such a direct BGP feed to be convenient but I expect all the larger network operators to use the BGP feed as a way of monitoring for changes which would be reviewed by some clueful operator before building the filters. That should not be a problem assuming that ARIN issues addresses every weekday. I guess monitoring NANOG or some other mailing list for announcements is somehow a lot more work. Oh well. Alec - Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
Re: Operational Issues with 69.0.0.0/8...
--On Monday, December 9, 2002 14:41 + [EMAIL PROTECTED] wrote: I consider this to be more of a minor technical issue. ARIN can certain provide an authoritative directory for the unallocated portions of its own allocations. And to answer your why question; because only ARIN has an authoritative and up-to-date view of exactly which addresses are and are not allocated. What on earth gives you that idea? Why does only ARIN have this information? Just because it happens to reside in their whois server? Alec -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
Re: Operational Issues with 69.0.0.0/8...
--On Monday, December 9, 2002 9:48 -0500 Leo Bicknell [EMAIL PROTECTED] wrote: The problem here is that ARIN (and the other registries) are the ones who can contact the users. But Michael is not talking about the registries _contacting_ people with a message about changes in unallocated blocks, he's talking about one specific regional registry providing a list of all unallocated space (that still 'belongs' to IANA/ICANN). The registries already provide notification about new allocations they receive, though not to individual users. Alec -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
Re: Operational Issues with 69.0.0.0/8...
So here's a question for people. For those who filter, what about the real-time feed that people want from the RIRs is different from this: lynx -dump http://www.iana.org/assignments/ipv4-address-space | grep IANA - Reserved ? Alec -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
Re: Operational Issues with 69.0.0.0/8...
--On Monday, December 9, 2002 15:43 + [EMAIL PROTECTED] wrote: Yes, spewing out email to solve a simple database synchronization problem seems counter-productive to me. Even a plain ASCII text file mirrored with rsync polling would be a vast improvement over email. But LDAP is proving to be the direction that the world is moving in for this type of directory service so why not leverage the tools and expertise that are available out there? lynx -dump http://www.iana.org/assignments/ipv4-address-space | grep IANA - Reserved ? Alec -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
Re: Operational Issues with 69.0.0.0/8...
OK, clearly this discussion has mutated into a couple of discussions. I was under the impression we were still talking about a published list of /8 delegations, since all of the prefix filters I've seen operate on that level. However, part of the discussion has mutated into how the RIRs should provide insight into unallocated space inside of delegations they have received from IANA. There are several issues. There is the operational issue relating to people who have received allocations inside of 69/8 and cannot get to backbones who are filtering announcements from that block. I'd say it's safe to assume that the backbones who are filtering 69/8 aren't reading NANOG, so the fact that the operational discussion is happening here probably isn't doing much good to help Todd's problem. As far as how to fix that, somebody probably needs to find the right person at these ISPs and use a clue-by-four appropriately. Then there is the registry issue of how to provide relevant information about which /8s belong to which RIRs. I respectfully suggest that people periodically query http://www.iana.org/assignments/ipv4-address-space for this information. Finally, there is the issue of providing information relating to unallocated blocks within each RIRs allocations. This discussion is far more relevant to the registry specific mailing lists. I suggest those interested in discussing that join the appropriate ARIN mailing list. The discussion is happening on [EMAIL PROTECTED], though it is probably more appropriate to the [EMAIL PROTECTED] mailing list. Alec -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
Re: Operational Issues with 69.0.0.0/8...
Putting on my hat as ARIN AC Chair --On Friday, December 6, 2002 16:57 + [EMAIL PROTECTED] wrote: This is no longer a technical operational issue so it is out of scope for this mailing list. But if you think that ARIN could do something to solve your problem then you should raise the issue on the ARIN public policy mailing list. You can find subscription information for that list here http://www.arin.net/mailing_lists/index.html I see this as purely an operational issue. ARIN explicitly does not guarantee routability of prefixes it assigns. If service providers choose to filter ARIN allocations, then that is an operational decision. I really don't see what action you expect ARIN to take along these lines. Alec -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
Re: Operational Issues with 69.0.0.0/8...
--On Friday, December 6, 2002 13:48 -0600 Stephen Sprunk [EMAIL PROTECTED] wrote: This is a case of ARIN knowingly assigning unusable space to customers. There's a huge difference there. So for the sake of argument, in your proposal an ISP could filter all of the blocks that the RIRs allocate out of and hamstring them indefinitely? Alec -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
RE: Operational Issues with 69.0.0.0/8...
--On Friday, December 6, 2002 15:29 -0500 Sean Donelan [EMAIL PROTECTED] wrote: Sorry, which operational aliases did the RIRs announce before they started allocating addreses? ARIN announced the fact that it received the 69/8 delegation on August 8th. ARIN received the delegation on August 6th. ARIN made its first allocation/assignment (I don't know which it was, but that isn't important) out of that block on September 19th. So, that's over 1 month that people had to fix their filters. We're in December now, and clearly some people still haven't updated their filters. Do people have any suggestions for ARIN (and other RIRs) on how they can better dissemenate this information so that people will update their filters? Alec -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
RE: Operational Issues with 69.0.0.0/8...
Sorry, the announcement was made on NANOG. Alec --On Friday, December 6, 2002 13:44 -0700 Alec H. Peterson [EMAIL PROTECTED] wrote: --On Friday, December 6, 2002 15:29 -0500 Sean Donelan [EMAIL PROTECTED] wrote: Sorry, which operational aliases did the RIRs announce before they started allocating addreses? ARIN announced the fact that it received the 69/8 delegation on August 8th. ARIN received the delegation on August 6th. ARIN made its first allocation/assignment (I don't know which it was, but that isn't important) out of that block on September 19th. So, that's over 1 month that people had to fix their filters. We're in December now, and clearly some people still haven't updated their filters. Do people have any suggestions for ARIN (and other RIRs) on how they can better dissemenate this information so that people will update their filters? Alec -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
