Re: [sig-policy] prop-082: Removing aggregation criteria for IPv6 initia
On 04/02/2010, at 5:30 PM, (Tomohiro -INSTALLER- Fujisaki/藤崎 智宏) wrote:
> |
> | can you highlight the exact section in the IPv6 policies where subsequent allocation do not require aggregation?
>
> Current IPv6 policy:
>
> http://www.apnic.net/policy/ipv6-address-policy
>
> describes the initial allocation criteria at section 5.1.1, and the
> subsequent allocation criteria is defined at 5.2.1. The subsequent
> allocation criteria is now an utilization requirement only.
>
To be honest I haven't thought of this section in light of _not_ requiring aggregation.
Are there any examples in the v6 BGP tables and known filters that demonstrates subsequent allocations are permitted to de-aggregate?
I know this doesn't change your argument about removing aggregation, I'm just questioning the assumption that initial allocations and subsequent allocation are handled differently. ergo I think a broad brush approach should be that ALL v6 aggregation requirements are removed.
>
> I agree prop-73 did not intent that, but the implementation will have no
> concern about the aggregation.
>
I'm not sure that I agree with your tight interpretation.. Do others (including the secretariat) read that? Do the people who write the filter ACLs read that?
>
> I think this is one discussion point.
>
> Aggregation in IPv6 will be more important than IPv4 since IPv6
> address has longer bit length, will have more routes than IPv4 (I
> hope so:-)),
Again are you sure? I can't be as I don't have a crystal ball, and actually at times I think that the routing system size for v6 will look something closer to a number defined by the AS count (currently about 33263) multiplied by some traffic engineering factor(1). But then that factor is totally variable. But this is probably a beer discussion.
(1: as opposed to what we see now in terms of a hierarchical origin map, see http://stats.research.icann.org/bgp/)
> and some backbone routers will have to maintain both IPv4
> and IPv6 routes. So I want to emphasize importance of aggregation to
> suppress de-aggrigation without any technical requirement in this
> document.
right
>
> I'm sorry this may be over-description, but my intention here is that
> this policy will reduce number of requirements.
Right. But they are "post allocation" requirements.
>
> Yes, I also think that is one advantage, but I'm not sure it will work
> in the initial allocation size, almost all of them are /32 in the
> global internet context, in which many routers may filter longer
> prefix thant /32.
>
Sorry to put on the pedant hat. routers only filter prefix lengths that they are told to by the organisations that run them.
>
> | >
> | > 7. Effect on NIRs
> | > ------------------
> | >
> | > None.
> | >
> |
> | really??
>
> Should I add something like 'NIRs should implement same policy ...' or
> do you have other concern about NIRs?
I don't know. Thats why I was asking :-)
Cheers
Terry