-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>Consider an ISP that receives an allocation of a /20 prefix from source
>A, and an allocation of an adajecnt /20 prefix from source B, but wants
>to issue an advertisement for the aggregate /19 prefix.
>>>>> "Sandy" == Sandy Murphy <[EMAIL PROTECTED]> writes:
Sandy> I believe that there was another wrinkle to the issue.
Sandy> (Since I was the one who raised it, I know what I *meant*,
Sandy> although others might have heard differently.)
Sandy> The issue is that some RIRs, when allocating a prefix, will
Sandy> reserve a matching adjacent prefix for future requests, so
Sandy> that the two allocations are aggregatable. This helps limit
Sandy> routing table bloat. Note the difference: this is a *single*
Sandy> source allocating multiple aggregatable allocations. And I
Sandy> believe that it happens frequently, by deliberate process.
Sandy> (Actually, I'm having trouble visualizing allocations from
Sandy> *multiple* sources that are aggregatable - perhaps this only
Sandy> happens when ranges rather than prefixes are involved? I'm
Sandy> lazy and I don't want to do the math - if you have an example
Sandy> of *prefixes* allocated from multiple sources that were
Sandy> aggregatable, could you describe it?)
I think that it would be exceedingly rare.
For it to occur, the two sources would have to have received
allocations from a parent RIR that were not powers of two. Even if
source A had been allocated:
A: 10.10/16 and had delegated 10.10.240.0/20
B: 10.11/16 and had delegated 10.11.0.0/20
no aggregatable /19 would be posssible. yes, a range from 10.10.240.0
to 10.11.15.255 exists, but it wouldn't aggregate.
The case where additional address space is allocated (as Sandy
mentions, from the same RIR) seems simpler to me.
You give a reason why the RIR couldn't just issue the /19 certificate
at that point:
Sandy> it is from a single source. But the architecture notes that
Sandy> an RIR (or a source further down the allocation chain) might
Sandy> not always want to create a cert for the aggregate, as the
Sandy> validity times of the two longer prefix allocations might be
Sandy> different. Hence the need for multiple certs, and the choice
Sandy> between either interpreting the validity of a BGP UPDATE
Sandy> based on multiple (singly signed) ROAs or multiply signed
Sandy> ROAs.
But, if the validity times are significantly different such that one
prefix is going to change prior to the certificates expiring, should the
ISP really even be advertising the aggregate?
- --
] Bear: "Me, I'm just the shape of a bear." | firewalls [
] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[
] [EMAIL PROTECTED] http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Finger me for keys
iQEVAwUBRrBZmYCLcPvd0N1lAQKevAf8C9/iJcrBU40yRxLjUD+i2yjmYpmVHETH
gk0zkoAy9M+9rR13MZfKeEI49h+MuV9/ylxz0zskZF59VfV0GHwITHk0e1sLne5V
/7gt0c7O4dg0Av9JAWyfMblX821GsqKadZeVtGiSW5VpoQIcAwxKaVBk7rOeSDgE
VHMKjo59IvDCdD1/PJota21fEWbR8uJO0uaLgYIdtn5nRnNQFjSkug400NsaIG99
ZdMIUBVmMa/f/rv/eKyh08Xovvg2km70eIWU22eDjZvYpuZHpCMrKZiT0R1KAPzG
9WmaLXTsOepCQnOkKJ3t3xCjmkKsW2KMuvUdeq0Fz+jew8xxF1873Q==
=0z2q
-----END PGP SIGNATURE-----
_______________________________________________
Sidr mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/sidr
