Not really. If you split the block into an AUP compatible group and a non-AUP compatible group, then you send in 2 routes in some cases instead of one. Thus you still save a large amount of route table space.
Thanks, Milo
Milo, Who's AUP? US FED? If we allow one AUP per country we need 200+, and then we need tosplit in smaller blocks to find the smallest block of networks that meets that.. How about everyone implement their own AUP on their side, using the information in the routing registry (wich may go down to host policies). Static route packets to people you don't want to talk to into a black-whole-gw. -Peter
I don't know how you can implement AUP in the network in a reasonable way using the approach you propose. You move a centralized management problem into a much more distributed and harder to effect approach. I still don't understand the problem. You split your block into a non-AUP and AUP block, and advertise the ranges appropriately. This is consistent with the existing model of how routes are advertised and approved, and requires no changes in the system. We use the same techniques we are doing today. If we reduce specific advertisements from 500 to 2, instead of 500 to 1, we still win. Thanks, Milo
From: "Milo S. Medin" (NASA ARC NSI Office) <medin@nsipo.nasa.gov> Subject: Re: 20402 routing entries We use the same techniques we are doing today. If we reduce specific advertisements from 500 to 2, instead of 500 to 1, we still win. Milo, In the worst case it stays at 500 to 500.. you're forcing people to renumber to deal with one transit network's AUP. If I was responsible for the Latvian national backbone, and I demanded that you gave up CIDR benefits or force your customers to renumber, wouldn't you be a bit irked? Enforcing the AUP -must- be the sole responsibility of the network that has the AUP constraints. That's the way everyone else has been doing things. We got away with the NSF AUP because we still had a strong concept of a core. Heck, how many of us still (until recently) called the NSFnet the "backbone"? I know I did. There is no "core" anymore, NSF, ES, and NSI are transit clouds in a tangled web. If someone needs to play policy games, they, and their customers, should be the ones forced to pay for it. Paul
That's all fine and good, however it has little to do with the issue of reducing the number of routes. Your worst case of 500 staying 500 is more likely due to problems in getting BGP4 deployed than any AUP issue. You hurt your credibility when you try and blame all the world's problems on AUP's. We need to try and make sure we have stable BGP4 code bases out there in multiple vendor's routers, and understand how all the backdoors are supposed to be handled first... Thanks, Milo
To: Paul Traina <pst@cisco.com> Cc: Peter Lothberg <roll@stupi.se>, David R Conrad <davidc@terminus.iij.ad.jp>, Vadim Antonov <avg@sprint.net>, ALH@eagle.es.net, bgpd@merit.edu, eowg@fnc.gov, routing-wg@ripe.net, yakov@watson.ibm.com Subject: Re: 20402 routing entries Date: Fri, 15 Apr 94 13:15:20 -0700 From: "Milo S. Medin" (NASA ARC NSI Office) <medin@nsipo.nasa.gov>
That's all fine and good, however it has little to do with the issue of reducing the number of routes. Your worst case of 500 staying 500 is more likely due to problems in getting BGP4 deployed than any AUP issue.
You hurt your credibility when you try and blame all the world's problems on AUP's.
I'm sorry to disagree with you Milo, but I think you were the one who brought up the concept of going from 500 to 2 vs 500 to 1, with the "2" being necessary because Andrew's customers needed to migrate into an AUP block vs a non-AUP block. If I misunderstood what you were saying, could you please clarify? My point is the same one that Andrew was making -- right now, he's got customers randomly scatters as AUP and non-AUP. For every non-AUP net, he's got, we end up poking serious holes into CIDR efficiency. All it takes is, say, 30 randomly scattered holes to make a complete mess of the 500 to 2 argument.
We need to try and make sure we have stable BGP4 code bases out there in multiple vendor's routers, and understand how all the backdoors are supposed to be handled first...
I think we're already past that point, there are multiple vendors with reasonably stable code. Best regards, Paul
participants (3)
-
Milo S. Medin -
Paul Traina -
Peter Lothberg