[regional-russia] RE: [regional-russia]

[<a.koryukov@localhost]

Невижу особых проблем с 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@localhost 
> [
	    
	    
] On Behalf Of Dmitry Kiselev
> Sent: Friday, May 04, 2007 2:37 PM
> 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
> 
>