ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: Inet-Admins
Inet-Admins mailing list archive (inet-admins@info.east.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[inet-admins] =?koi8-r?B?UmU6IFtpbmV0LWFkbWluc10gUmU6IFtpbmV0LWFkbWluc10gxNfFIA==?==?koi8-r?B?z9LHwc7J2sHDycksIM/Eyc4gzs/NxdIgQVM=?=



Что можно сказать... здоровый бюрократизм RIPE позволяет сдерживать
торопливых коммерсантов, которые потребляют адресное пространство как
расходный материал, коим адреса не являются. Это скорее жизненное
пространство, типа гектара земли, на ограниченном земном шарике.
Кроме того, есть ещё замечание: _каждая_ организация, сталкиваясь с
необходимостью в резервировании своего подключения к Интернету, желает
сэкономить на регистрации LIR, получив PI. Но смотреть надо не только на
сиюминутную необходимость независимой маршрутизации, а на те мотивы, которые
заставили организацию пойти на такой шаг. Основной причиной является
повышение коэффициента доступности и качества предоставляемых конечным
пользователям услуг (для операторов связи), и, в гораздо меньшей степени -
повышение доступности Интернета из своей сети (для корпоративных
пользователей, являющихся конечными потребителями, т.е. не предоставляющих
услуги связи). В случае если организация собирается продавать доступ (а
значит маршрутизировать сети клиентов), в дальнейшем её необходимо будет
вести базу inet-num для клиентов на своём адресном пространстве, которое
выдал RIPE при регистрации LIR (исходя из полиси RIPE, например 5.1.2
Registration Requirements в документе
http://www.ripe.net/ripe/docs/ipv4-policies.html#5.1.2)
В случае с PI это невозможно, поскольку в данном случае не даётся
X-NCC-RegID.
Посему ISP желающие иметь резервирование подключения должны получить LIR
(кроме резервирования они получают полную независимость в Сети и полноту
возможностей, которые на тот момент они не осознают ;)
В случае с корпоративными пользователями следует пользоваться соображениями
целесообразности выделения PI, поскольку каждый PI загромождает fulltable
BGP и админы незаинтересованы в её увеличении;) Кроме того есть официальный
документ: http://www.ripe.net/ripe/docs/pi-pa.html

В качестве ответа на первоначальный вопрос данного треда хочу указать
следующее:
http://www.ripe.net/ripe/docs/asn-assignment.html
1.0 AS Number Assignment Policies and Procedures
An Autonomous System (AS) is a group of IP networks run by one or more
network operators that has a single and clearly defined routing policy.

В случае, если адресное пространство выносится на несвязанный сегмент сети
данное определение не работает.
Может всё таки проблема совсем в другом? Может вашему B намекнуть на то, что
мол доступность ваших услуг заставляет ожидать лучшего?-) Или взять
подклучение у A? В любом случае LIRы дают любое обоснованное количество
адресов своим клиентам и непонятна необходимость пользоваться пространством
провайдера A в сети B.
Кстати, в некоторых случаях вынос адресного пространства на VPN так же имеет
свои причудливые применения.

С уважением,
Vladimir Tregub (VT60-RIPE)
CCS NOC

PS: в добавление хочу сказать, что расширение адресного пространства с
протоколом IPv6 не облегчит жизнь, поскольку раздача адресного пространства
всё равно должна быть продуманной, что бы сеть осталась жизнеспособной и
частные роутинговые политики управляемыми.

----- Original Message -----
From: "Alexander Ilushin" <ilu@a5.kiam.ru>
To: <inet-admins@info.east.ru>
Sent: Thursday, October 17, 2002 11:01 AM
Subject: [inet-admins] Re: [inet-admins] две организации, один номер AS


> Мы столкнулись с этой ситуацией 3 месяца назад в роли организации В. Дело
> заканчивается тем, что мы находимся на самом последнем шаге получения LIR.
> Тем не менее хочется поделиться опытом борьбы за существование без
> LIR(естественно проблема в деньгах).  С моей точки зрения проблем в самой
> сети практически нет - more specific route object совершенно законен.
> Достаточно, чтобы только эти два провайдера принимали  объявление этого
> объекта,  между провайдерами очевидно есть связь на уровне, например,
M9-IX,
> а в остальной мир должен пойти агрегированный префикс. Если есть
техническая
> целесообразность, то в идеале не должно быть и нормативных запретов на эту
> техническую эффективность (по крайней мере мы никаких запрещающих
документов
> не нашли). На деле все закончилось на нежелании организации А разбираться
с
> этими проблемами (наш провайдер был согласен). Приходиться теперь кормить
> чиновников в RIPE, которые в ответ на наш запрос блока PI +AS# (по всем
> формальным критериям мы прошли) предложили LIR. С технической точки зрения
> PI+AS# и LIR+PA+AS#, как мне кажется, совершенно равнозначны. Только
первый
> вариант без денег для RIPE. Результат очевиден.
>
> Alexander Ilushin, AII1-RIPE
>
> ----- Original Message -----
> From: "Victor Sudakov" <vas@mpeks.tomsk.su>
> To: <inet-admins@info.east.ru>
> Sent: Thursday, October 17, 2002 6:54 AM
> Subject: [inet-admins] две организации, один номер AS
>
>
> > Уважаемые коллеги, пример из жизни.
> >
> > Организация A, имеющая статус LIR, выдает организации B блок сетей.
> > Организация B объявляет этот блок сетей с номером AS, принадлежащим A.
> > Провайдеры у A и B разные.
> >
> > Насколько такое допустимо с точки зрения RIPE? Не должна ли была A
> > получить для B отдельный номер AS? Техническую проблему вижу пока
> > только одну: A и B не увидят друг друга в своих таблицах, но это
> > решаемо.
> >
> > Большая просьба подкрепить ответ ссылкой на соответствующие документы
> RIPE.
> > Заранее спасибо.
> >
> > --
> > Victor Sudakov,  VAS4-RIPE, VAS47-RIPN


=============================================================================
"inet-admins" Internet access mailing list. Maintained by East Connection ISP.
Mail "unsubscribe inet-admins" to Majordomo@info.east.ru if you want to quit.
Archive is accessible on http://info.east.ru/rus/inetadm.html



 




Copyright © Lexa Software, 1996-2009.