Ref: Your note of Thu, 14 Apr 1994 16:49:22 +0200 It would be really nice if all the new destinations that can be CIDRized be announced ONLY via CIDR blocks without individual components. Is that the current practice ? And if not, then what can be done to put this in place ? Yakov.
Yakov, The way I read your message is that all new network numbers should be CIDRized and fundamentally not be portable between service providers. This is a bit rigid. Shouldn't there be another option that allows portability too? Marty
Ref: Your note of Thu, 14 Apr 1994 16:49:22 +0200
It would be really nice if all the new destinations that can be CIDRized be announced ONLY via CIDR blocks without individual components. Is that the current practice ? And if not, then what can be done to put this in place ? Yakov.
Yakov,
The way I read your message is that all new network numbers should be CIDRized and fundamentally not be portable between service providers.
This is a bit rigid. Shouldn't there be another option that allows portability too?
Marty
If a component moves, and does not want to renumber, the old provider should announce an unreachable for the component (that is obviously more specific than the aggregate) and the new provider should announce the component that moved. You should ask the customer to renumber and explain why and strongly urge then to do so. I don't think anyone is advocating forced renumbering (are they)? Curtis
We've seen forced renumbering already being done. I'll defer my remarks on whether this is good or bad. Thinking of scaling in the future why does the old ISP want the administrative burden of configuring "unreachable" and then offer the computational burden to the entire Internet of a "unclean" CIDR block. And the new ISP putting a standalone network number which needs to be computed upon. CIDR seems like a future lose-lose situation unless the blocks are clean. And the larger the blocks the bigger win. These should be the goals for the future. "Strongly urge" seems like the cows are out of the barn already for us old dirt farmers. Marty
If a component moves, and does not want to renumber, the old provider should announce an unreachable for the component (that is obviously more specific than the aggregate) and the new provider should announce the component that moved.
You should ask the customer to renumber and explain why and strongly urge then to do so. I don't think anyone is advocating forced renumbering (are they)?
Curtis
-------- ] From: Martin Lee Schoffstall <schoff@us.psi.com> ] Subject: Re: 722 Nets, 23 ASs, 98 Aggregates ] Date: Thu, 14 Apr 1994 15:54:05 -0400 ] ] We've seen forced renumbering already being done. I'll defer my remarks ] on whether this is good or bad. ] ] Thinking of scaling in the future why does the old ISP want the administrative ] burden of configuring "unreachable" and then offer the computational ] burden to the entire Internet of a "unclean" CIDR block. And the new ] ISP putting a standalone network number which needs to be computed upon. ] ] CIDR seems like a future lose-lose situation unless the blocks are clean. ] And the larger the blocks the bigger win. A site which doesn't renumber will need to have his more specific route propogated to the far corners of the Internet. 1) Anyone care to estimate how much this route costs to the combined set of multiply-connected providers and sites? (Need to include router memory, forced introduction of new routers, update bandwidth, etc. for every affected network...) 2) Given the answer to #1, is there some way to recover these costs? /John p.s. (Yes, I can hear the booing and hissing starting already... :-)
Curtis Villamizar <curtis@ans.net> writes:
You should ask the customer to renumber and explain why and strongly urge then to do so.
Exactly.
I don't think anyone is advocating forced renumbering (are they)?
There are people who do. I observe that none of them is dealing with customers as an ISP or Internet registry. Challenge?
participants (5)
-
Curtis Villamizar
-
Daniel Karrenberg
-
John Curran
-
Martin Lee Schoffstall
-
yakov@watson.ibm.com