Re: [sig-policy] prop-082: Removing aggregation criteria for IPv6 initia
Hi Terry,
Thank you again for your reply.
I'm sorry not to reply sooner.
| > | 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 have no example about that. I think currently, there are not so many
subsequent allocation in IPv6, and filters will be based on the
minimum allocation size, such as /32.
# I'd found there were some (many?) specific routes perhaps in
# initial allocation blocks.
| 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.
At least I've heard discussions in an LIR about IPv6 de-aggregation and
initial and subsequent allocation policy description. Personally, I think
current policy description, which clearly stated aggregation requirement
in one case, and no such description in another leads some people think
in later case de-aggregation is permitted.
| > 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/)
I understand your point about a number of routes which will appear in
IPv6 world, and I agree your estimation. They will be closer to a
number of ASes (but upper limit is extended to 32bit:-)).
| > 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 :-)
OK, I'll add to my proposal document.
--
Tomohiro Fujisaki