filtering /48 is going to be necessary

Sat Mar 10 06:14:32 UTC 2012

On Fri, Mar 9, 2012 at 11:33 PM, Joel jaeggli <joelja at 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