Re: [sig-policy] prop-076: Requiring aggregation for IPv6 subsequent all
(Tomohiro -INSTALLER- Fujisaki/藤崎 智宏) said the following on 7/8/09
00:58 :
>
> | Every AS has traffic engineering needs, and that can't be achieved with
> | just a single announcement. :-(
>
> Do you mean many ASes who request additional address block will have
> an intention to announce de-aggregated prefixes? I think a large
> initial allocation will be same in this sense.
They won't deliberately announce their /32 as 256 /48s, but how should
they do traffic engineering from a single site with two external links?
That's why I was referring to RIPE-399 which encourages prudency. And
then there are significant numbers of organisations who have the sort of
infrastructure that Skeeve mentioned. How would you do the "must
aggregate" to them - unless they can get a /32 for each independent site?
> As a viewpoint of traffic engineering, I heard the proposal to remove
> aggregation requirement from the initial allocation criteria in LACIC
> mentioned this point as one main reason.
I wouldn't remove an aggregation requirement, I would use the word
"should" rather than "must", with a reference to what are considered
industry good practices. That's all I'm questioning. :-)
> And we had related discussion in last JPOPM. The discussion summary
> is, we understand there are many demands to announce de-aggregated
> address block for traffic engineering, but still we should state this
> point somewhere in the policy document, not in the supplement document
> like guidelines.
No argument from me here.
> | Would it be worth augmenting the proposal by stating that "recipients of
> | further IPv6 allocations should attempt to minimise the deaggregation of
> | the allocation as much as is technically feasible".
>
> Thank you so much for drafting the elegant sentence! Do you think this
> can be inserted as a 'subsequent allocation criteria' in the policy
> document? (Then, I think 'should' should be changed to 'have to', and
> it would be no big difference in this case.)
As long as policy recognises traffic engineering requirements and the
needs of disconnected sites, I think I'd be content.
philip
--