On Fri, Mar 9, 2012 at 11:33 PM, Joel jaeggli <joelja@bogus.com> wrote:
On 3/9/12 20:42 , Owen DeLong wrote:
Because my network is discontiguous I must announce more specific routes than the assignment in order to reflect the topology I have both in IPV4 and in IPV6.
I fully expect (and have no evidence to the contrary) that my transit providers will accept the deaggreated prefixes and that their upstreams and peers will by-in-large do likewise.
I have no doubt any transit provider would be happy to provide the transit for your discontiguous network, and accept your deaggregates within their network. The unreasonable expectation is that their upstreams or peers would carry all the deaggregates in the long run. Connectivity for your discontiguous networks are your problem to solve, and as long as router memory is at a premium, limiting what deaggregates are accepted will be important. The peers want best connectivity to you at least cost for them.
I have no interest in the general sense of deaggregating beyond the level required by the topological considerations.
You don't have such an interest, but sloppy practices prevail on average. As evidenced in IPv4 by large blocks with all the /24s showing up.
Imposing arbitary political considerations on organizations that are
Not political considerations, technical restrictions, which are design constraints. There are already plenty such design constraints that are imposed by RFC; interconnecting networks doesn't have a reliable result without some technical ground rules that provide for interoperability, stability, and predictability.
simply trying to operate networks in order preserve maximal aggregation at a given level seems absurd on the face of it.
So for any network you provide transit to, in IPv4 you would be happy to allow them to announce their /12 as 13,1072 /29s, because they have 131072 subnets, and they could reasonably expect that all your peers would be happy to propagate the /29s, for the purpose of making sure the end user's design is not constrained (although at the peer's expense for increased equipment capacity) ? There's an unwritten rule somewhere, that you don't expect longer than a /24 to propagate far with high degree of certainty. With IPv6 instead of picking some arbitrary number liek /48 or /64, it should be based on the RIR allocation unit size and type of allocation, for best results. That's more rational than what we have with IPv4 -- -JH