Невижу особых проблем с PA. Во-первых, откуда проблемы scalability при таких размерах (/16). Скорее всего будет дробление allocation на две равные части. Во-вторых, кто мешает написать заявку на PA assigment размером /16 - /17 (или менее, но обосновано). Далее, в связи с тем что нехватает ресурсов в существующих allocations (80% явно будет достигнуто), запрашивается ещё один PA allocation. А дальше уже как вам угодно или этот новый PA allocation прицепить, или из старого PA assigment (а можно и sub-allocation!) выделить. В-третьих, получить ещё один ASN. Меньше глюков с марщрутизацией. З.Ы. У нас так сделано, и всё прекрасно работает. Александр Корюков Руководитель группы IP ЗАО "Форатек Коммуникейшн"
-----Original Message----- From: regional-russia-admin@ripe.net [mailto:regional-russia-admin@ripe.net] On Behalf Of Dmitry Kiselev Sent: Friday, May 04, 2007 2:37 PM To: regional-russia@ripe.net Subject: Re: [regional-russia] Re: [regional-russia] Re: [regional-russia] Re[2]: [regional-russia] Re: [regional-russia] Re: [regional-russia] Re[2]: [regional-russia] Re: [regional-russia] Поддерж=koi8
Добрый день!
On Fri, May 04, 2007 at 11:03:22AM +0300, Max Tulyev wrote:
А в переход (полный) на ASN32/IPv6 я не верю. По крайней мере, это вопрос даже не нас, а наших внуков при таком подходе и ПОЛНЕЙШЕМ НЕПОНИМАНИИ текущих процессов участвующих в V6-миграции (в т.ч. и RIPE). И то не когда, а если.
Раз уж речь зашла о PA, PI и multihoming может кто-то из присутствующих поделится опытом... Есть филиал которому нужны адреса: /17-/16 в перспективе на пару лет. IP connectivity с ним сейчас нет и в ближайшее время не предвидится. В существующих allocations нет 80% занятости и есть блок нужного размера. Я вижу следующие варианты решения:
1. Выдать PA из своего allocation, зарегестрировать ASN для BGP origination и выпустить как more specific. Scalability при этом весьма сомнительна, зато - дешево. 2. Получить PI+ASN. benefits такие же как в предыдущем пункте. policy при этом не нарушается, так как end users там получают по 1 IP. Есть только сомнения в реальности /16 PI... 3. Уговорить NCC нарушить policy и выдать отдельный allocation. 4. Сделать филиал самостоятельным LIR.
Кто как подобные проблемы решает?
-- Dmitry Kiselev