This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[address-policy-wg] late comments on 2009-06
- Previous message (by thread): [address-policy-wg] 2009-03 New Draft Document Published (Run Out Fairly)
- Next message (by thread): [address-policy-wg] late comments on 2009-06
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Ruediger Volk, Deutsche Telekom T-Com - TE141-P1
rv at NIC.DTAG.DE
Tue Sep 22 22:38:44 CEST 2009
Dear colleagues, the last call for 2009-06 is very close to expiring... I'm sorry I'm coming this late with a few comments. I certainly support the the motion to remove from the contraints for routing announcements from the address allocation policy; I voiced my support already at the last RIPE meeting with strong words. I hope that Rob Evans' initiative to draft a document on recommended annoucement practices in IPv6 in routing WG will result in document providing guidance on usage of aggregates, more specifics etc. without unduely stressing the global routing system. Admittedly this will be much harder than the removal of a few words from existing policy text (as 2009-06 does). Recently a potential downside of the removal of routing constraints from allocation policy came to my attention: NCC resource analysts might begin to encourage or even force LIRs to plan to deaggragate announcements when discussing requests for address space. For the record: I'd strongly request that NCC should refrain from doing so until documents giving guidance on appropriate use of deaggregation, or announcements of more specifics have been written and agreed upon. Applying such restraint seems not to require explicit text in the allocation policy - though I can see that NCC using or not using such restraint can in some cases lead to different results in evaluating requests for address space; i.e. some times allocating an additional separate address block when using a more specific out of another allocation might be another way for solving a particular routing requirement. Before closing let me make another nit: I feel quite uncomfortable to see the the second paragraph the impact analysis for fragmentaion/aggregation: it would be better to ONLY have the "we cannot seriously estimate" of the first paragraph than juggle meaningless short sighted numbers. Regards, Ruediger Ruediger Volk Deutsche Telekom AG -- Internet Backbone Engineering E-Mail: rv at NIC.DTAG.DE Phone: +49 251 7985 200 fax: +49 251 7985 109
- Previous message (by thread): [address-policy-wg] 2009-03 New Draft Document Published (Run Out Fairly)
- Next message (by thread): [address-policy-wg] late comments on 2009-06
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]