Peter & Yakov,
We are at the point where action has to be taken, either to get CIDR the "proper way", or by forced proxy aggregation at some places in the Internet.
Let me suggest to pursue a combination of both. Folks who are willing and able to cooperate should pursue the "proper way", and the rest may be subject of proxy aggregation (which may be "forced").
You can't do proxy aggrigation without consent!!! You WILL create policy violations as well as destablizing global routing. Forget any concept of 'forced proxy aggregation'!!!! Tony
You can't do proxy aggrigation without consent!!! You WILL create policy violations as well as destablizing global routing. Forget any concept of 'forced proxy aggregation'!!!! Tony, yell all you like. How will you stop someone? As we mentioned at IETF, folks will have to do proxy aggregation unless there is substantial aggregation happening just so that they can survive. Tony
Tone, Tone, Tone sez: (What IS on the CD right now? :-(
You can't do proxy aggrigation without consent!!! You WILL create policy violations as well as destablizing global routing. Forget any concept of 'forced proxy aggregation'!!!!
Tony, yell all you like. How will you stop someone? As we mentioned at IETF, folks will have to do proxy aggregation unless there is substantial aggregation happening just so that they can survive.
I know one way to stop. Cut yourself off if the policy violations mandate it. Solves a bunch of problems, causes others. -- Regards, Bill Manning
You can't do proxy aggrigation without consent!!! You WILL create policy violations as well as destablizing global routing. Forget any concept of 'forced proxy aggregation'!!!!
Tony, yell all you like. How will you stop someone? As we mentioned at IETF, folks will have to do proxy aggregation unless there is substantial aggregation happening just so that they can survive.
Tony
I think it is safe to say that we will _not_ do proxy aggregation without first consulting the customer. Other providers might set different policies, but I doubt it. Curtis
I think it is safe to say that we will _not_ do proxy aggregation without first consulting the customer. Other providers might set different policies, but I doubt it. Well, that might be nice to start with, but if someone has routers crashing all over the place, they might not be so nice. I can easily envision someone aggregating west coast sites so that their east coast routers might live and vice versa. Don't get me wrong: I hope no one does have to resort to guerilla tactics. But as Vince points out, we face a serious problem with route flapping if any of the backbone providers starts having trouble. Tony
From: Tony Hain <ALH@EAGLE.ES.NET> Subject: RE: 20402 routing entries Peter & Yakov,
We are at the point where action has to be taken, either to get CIDR the "proper way", or by forced proxy aggregation at some places in the Internet.
Let me suggest to pursue a combination of both. Folks who are willing and able to cooperate should pursue the "proper way", and the rest may be subject of proxy aggregation (which may be "forced").
You can't do proxy aggrigation without consent!!! You WILL create policy violations as well as destablizing global routing. Forget any concept of 'forced proxy aggregation'!!!! Bullshit. If you have networks in the same AS, your service provider or peers will aggregate your networks. Policy is done ONLY on a per-AS basis. Those are the rules in this new world order, and if you don't like it, may I suggest that you try to find other folks to peer with who would rather roll over and die than violate your policy. Pissed Paul
You can't do proxy aggrigation without consent!!! You WILL create policy violations as well as destablizing global routing. Forget any concept of 'forced proxy aggregation'!!!!
Bullshit. If you have networks in the same AS, your service provider or peers will aggregate your networks. Policy is done ONLY on a per-AS basis. Those are the rules in this new world order, and if you don't like it, may I suggest that you try to find other folks to peer with who would rather roll over and die than violate your policy.
While I strongly agree that we have to aggregate or we will all die horribly painful deaths (or something like that), perhaps I'm fundamentally confused here. IIJ has a single policy, we have a single AS, but we have this problem that a large network to which some of our customers want to talk makes determinations based on network numbers. We can aggregate all of 202.32/16, but we either have to lie to the NSF and claim all customers in that block are AUP compliant or all the customers in that block can't get to the NSFnet. Therefore, we have to break 202.32/16 into pieces and some service provider up the wire may proxy aggregate for us. Or have I missed something obvious? Thanks, -drc
David R Conrad
IIJ has a single policy, we have a single AS, but we have this problem that a large network to which some of our customers want to talk makes determinations based on network numbers. We can aggregate all of 202.32/16, but we either have to lie to the NSF and claim all customers in that block are AUP compliant or all the customers in that block can't get to the NSFnet. Therefore, we have to break 202.32/16 into pieces and some service provider up the wire may proxy aggregate for us.
Or have I missed something obvious?
Actually, the best way to get another AS and split your aggregations that way. Use AS to define policy. -- Regards, Bill Manning
We can aggregate all of 202.32/16, but we either have to lie to the NSF and claim all customers in that block are AUP compliant or all the customers in that block can't get to the NSFnet. Actually, the best way to get another AS and split your aggregations that way.
There's no need to get another AS for this since the NSFnet does not care about ASes in this context - just use different CIDR blocks. But what happens when the NSFnet turns down a customer's request for AUP compliant access after we've allocated the address from the compliant block (hey, it could happen :-))? Or if the customer changes his mind and goes from compliant to non-compliant? We're going to tell him "renumber" - pretty good incentive to keep people AUP compliant (at least saying they are AUP compliant), no?
Use AS to define policy.
IIJ does. We have a single policy and with a single AS. The problem is that the biggest (?) network is interested in individual routes, not ASes. Of course, the NSF could de-aggregate all incoming CIDR blocks, then filter - after all, they're the ones who care :-) Thanks, -drc
David: I am speaking as an IDRP implementor, not as Registration Authority. Policy written on an AS basis may be able to take advantage of policy screening on an AS basis. This may make your long term policy easier to write. In bgp-4, you areable to write policy saying I don't want any routes from that AS coming to me. In IDRP, you can further say don't send my routes to these ASs, only to those. This advantage might cause you to put CIDRized aggregates into different AS over time. Of course, as Milo says, you can have different Aggregates with different policies in the same as. Just a thought, Sue Hares
Actually, the best way to get another AS and split your aggregations that way. Use AS to define policy.
-- Regards, Bill Manning
You don't need another AS, just a few more specific routes that can be used by the AUP world without carrying the aggregate. Curtis
Curtis Villamizar <curtis@ans.net> writes * * > Actually, the best way to get another AS and split your aggregations * > that way. Use AS to define policy. * > * > -- * > Regards, * > Bill Manning * * You don't need another AS, just a few more specific routes that can be * used by the AUP world without carrying the aggregate. ... which only works if that particular AUP world can or wants to do network based routing information filters .... -Marten
participants (8)
-
bmanning＠is.rice.edu -
Curtis Villamizar -
David R Conrad -
Marten Terpstra -
Paul Traina -
Susan Hares -
Tony Hain -
Tony Li