mt6561

Лечу из Киева в Москву 19-го Трансаэро UN202 (19:00), потом из Домодедова 19-го же UN109 (23:10) в Екатеринбург. Кто летит так же?

Есть ли на Иволге и в Екатеринбурге покрытие 3G/UMTS? Если да, то от каких операторов?

Если грамотно просить - все выдадут и проблем не будет. Обращайтесь =)

Зарегался. Будем голосовать :) P.S. Кстати, есть первая заявка на IPv6 PI. Тема таки интересна, как оказалось.

Кто следит за темой - с сегодняшнего дня доступны IPv6 PI ;)

Ну а чо мне еще делать-то? погодь, а ГМ разве не завтра? Ну а чо мне еще делать-то? погодь, а ГМ разве не завтра? Таки сегодня. И регистрация онлайн closed.

Сижу на Address Policy секции и слежу за новостями. Самое интересное буду выкладывать. Интересное: - IPv6 PI доступны с сегодняшнего дня. - APNIC и ARIN не принял полиси по последней /8. Ожидается поэтапное снижение максимального доступного для регистрации блока. RIPE думает. - Передача сеток от компании к компании: ARIN отказал, остальные думают. В RIPE - в проекте полиси можно передавать только PA, причем после передачи в течение 24 месяцев адресов ни одна, ни другая сторона не получит. Но это пока проект.

Подсажите пожалуйста, существут ли в природе и если да, то как зовется софт, который бы: - Принимал информацию о трафике в формате NetFlow и sFlow - Принимал Full View BGP - Разбирал трафик по BGP-направлениям. То есть говорил, что скажем, в сеть Голден Телекома - столько-то терабайт, с такой-то пиковой и средней скоростью, в М9 - столько-то и с такой-то - Показывал Realtime загрузку по сессиям по каналам, хотя-бы top-50. Чтобы понять, трафиком на какие айпишники/автономки сейчас в основном грузится канал. Цель - траблшутинг и осознание с кем имеет смысл пириться/подключаться, а с кем - не очень.

Да я туда в пятницу заглядывал, она совсем дохлая. Можно, конечно, и там беспредел навести... Не можно, а нужно. Если там будет ужас-ужас в схеме на 2010, то ее надо как минимум заблокировать. А простите, что? Всякие там реализации портабельных тоннельных айпи еще более угребищны. На самом деле - правда проста, как валенок. Если не хотите платить (нам ;) ) $100k за /24 в 2015-м - переходите на IPv6! Время еще есть. Критерий успешности перехода прост, как валенок: если 50% ресурсов (то есть сайтов) и пофиг сколько юзеров будет доступно через IPv6 - переход состоялся, если нет - значит, не получился.

Можно. Напишите на contact@ripe.net.Или можно просто подождать, пока они письмо пришлют.

100 за сетку - ты имеешь в виду просто PI любого размера либо сетку C-класса? 100 за факт поддержки исторической (старой) заявки. А рабочая группа, где можно обсуждать charging scheme зовется ncc-services-wg. Идем туда? Короткий и точный ответ: никак, верят на слово.Иногда требуют предоставить "статистику" и прочие графики. Зря они.. так мягко :) Пиаи вообще запретить надо было. Чтобы спекулянты вроде вас застрелились нафиг не мучаясь. В период кризиса было бы модно и актуально. Да безусловно! И айпишники выдавать поштучно из специального центра в ФСБ. За совсем-совсем другие деньги, ага.

Сергей, я тут сижу на райповских курсах (прямо сейчас в Киеве, ага), и вот что удалось выяснить. 8 мая начинается stage II - всем, у кого не будет договоров, будет разослано письмо о том, что у вас есть 3 месяца на то, чтобы заключить договор с любым лиром или напрямую с райпом (держите контакную информацию в хуизе корректной, ага). Если в течение 3-х месяцев реакции не последует - адреса заберут. Если контракт с лиром будет потом расторгнут со стороны лира, например, за неоплату - алгоритм тот же: письмо из райпа с просьбой определиться и 3 месяца на реакцию. Цена прямого контракта с Райпом завышена намеренно: их мнение - не выделывайтесь и берите LIR, раз уж можете/хотите иметь прямой контракт. Однако, в отличие от других регионов, где PI тарифицируются прямо, то есть поштучно - пока что в райповском регионе пиайки будут влиять на скоринг по стандартной charging scheme, что дает огромную вольность в создании тарифов лирами =) НО! Они блин говорят, "принимайте участие в создании charging scheme 2010 заранее"! И это меня пугает... Вобщем, вроде удалось затащить Xavier'а в кабак, завтра будут подробности :) P.S. Я думаю, для наших существующих клиентов цена года продления будет порядка $100 в год за сетку, для новых - равна стоимости регистрации, которая будет сильно снижена для больших блоков. Как-то так. Но это пока еще есть предмет обсуждения. P.P.S. Я так понял, фраза sponsoring LIR была переведена или понята неправильно. Речь не про спонсорство, когда кто-то кому-то что-то нашару дает, а о посредничестве этого LIR'а между RIPE и end-user. Формирование цены - исключительно право LIR'а.Текст договора тоже составляет он сам, на local language даже, а вот пункты, которые ОБЯЗАТЕЛЬНО там должны присутствовать, описано в соответствующем документе.

Исчез один маааааленький абзац: "во внимание принимаются только те PI и AS, которые были получены в прошлом биллинговом периоде (календарном году)". А так - все то же. DHL гарантированно доходит. А если и не доходит - то всегда можно проследить почему.Главное - получить от отправителя номер тикета и следить, что происходит, на сайте DHL. И если там будет "не может быть доставлено, потому что блаблабла" - звоним к ним в офис, назваем номер тикета и говорим им чо делать. Или - дешево и сердито - просто приезжаем к ним в офис и забираем письмо.

Собственно, с чем всех и поздравляю. И сделано это было через жопу, как обычно, и жопой же и думая, простите за мой французский. Таким образом, что LIR'ам "вспомнили" все те объекты, которые они регали n лет назад. И многие из-за этого вместо привычной категории small или extra-small вдруг сегодня обнаружили, что стали полноценными LARGE'ами, ага. С увеличением годовой оплаты вдвое-втрое. P.S. На наших существующих клиентах это никак не скажется, как минимум до того, как RIPE выработает схему как можно заставить неплательщика заплатить ;) Но вот новые... на днях придется-таки ввести ежегодную оплату. P.P.S. Зато появилась возможность прямого контракта с RIPE'ом для владельцев PI'ев. По цене лира и без права голоса, ага.

Конкретика проста: требовать наличие письменного контракта между владельцами PI и LIR/RIPE. Зачем? Чтобы ловить дохлые конторы, на которых мертвым грузом зависли адреса, а так же чтобы иметь "бумажный" путь ответственности до каждого адреса (скажем, было кому предъявить судебный иск). Будет ли такой контракт бесплатным? Однозначно нет. P.S. А вот почему надо городить огород вместо того, чтобы просто вернуть ежегодную тарификацию PI LIR'ам (и далее все произойдет автоматически) - увы не знаю.

PDP Number: 2007-01 Direct Internet Resource Assignments to End Users from the RIPE NCC Dear Colleagues, The proposal described in 2007-01 is now at its Concluding Phase. This proposal states that a contractual relationship between an End User and a sponsoring LIR or the RIPE NCC must be established before the End User receives Internet number resources (Autonomous System (AS) Number, Provider Independent (PI) IPv4 and IPv6, Internet Exchange Point (IXP) and anycasting assignments) directly from the RIPE NCC. It also states that the text in the policy should mention more explicitly that PI assignments can not be sub-assigned. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2007-01.html Please e-mail any final comments about this proposal to address-policy-wg@ripe.net before 5 May 2008. Regards Filiz Yilmaz RIPE NCC Policy Development Officer Так что - кто не успеет - тот опоздает и будет платить за PI не разово, а ежемесячно! :)

Dear all, The discussion period for the proposal described in 2008-03 has ended. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2008-03.html Summary of Proposal: This policy describes the process for the allocation of the remaining IPv4 space from IANA to the RIRs. When a minimum amount of available space is reached, one /8 will be allocated from IANA to each RIR, replacing the current IPv4 allocation policy. Draft Policy Text: New Text: In order to fulfill the requirements of this policy, at the time it is adopted, one /8 will be reserved by IANA for each RIR. The reserved allocation units will no longer be part of the available space at the IANA pool. IANA will also reserve one /8 to any new RIR at the time it is recognized. The process for the allocation of the remaining IPv4 space is divided in two consecutive phases: 1. Existing Policy Phase: During this phase IANA will continue allocating IPv4 addresses to the RIRs using the existing allocation policy. This phase will continue until a request for IPv4 address space from any RIR to IANA either cannot be fulfilled with the remaining IPv4 space available at the IANA pool or can be fulfilled but leaving the IANA remaining IPv4 pool empty. This will be the last IPv4 address space request that IANA will accept from any RIR. At this point the next phase of the process (Exhaustion Phase) will be initiated. 2. Exhaustion Phase: During this phase IANA will automatically allocate the reserved IPv4 allocation units to each RIR (one /8 to each one) and respond to the last request with the remaining available allocation units at the IANA pool (M units). 2.1. Size of the final IPv4 allocations: In this phase IANA will automatically allocate one /8 to each RIR from the reserved space as defined in this policy. IANA will also allocate M allocation units to the RIR that submitted the last request for IPv4 addresses. 2.2. Allocation of the remaining IPv4 Address space: After the completion of the evaluation of the final request for IPv4 addresses, IANA MUST: A) Immediately notify the NRO about the activation of the second phase (Exhaustion Phase) of this policy. B) Proceed to allocate M allocation units to the RIR that submitted the last request for IPv4 address space. C) Proceed to allocate one /8 to each RIR from the reserved space. Rationale: The IANA pool of allocation units of IPv4 addresses (/8s) is decreasing rapidly; the exhaustion of IPv4 address space is projected to take place within the next few years and to continue applying a global coordinated policy for distribution of the last piece(s) of each RIR's unallocated address block does not match the reality of the situation in each RIR region. Issues each RIR region will face during the exhaustion period vary by region as the level of development of IPv4 and IPv6 are widely different. As a result, applying a global coordinated policy may adequately address issues in a certain region while it could not be work for the others. For example, in a region where late comers desperately need even small blocks of IPv4 addresses to access to the IPv4 Internet, a policy that defines the target of allocations/assignments of IPv4 address space to the late comers would be appropriate in such region. This would allow availability of IPv4 address space for such requirements for more years. Another example comes from difference in IPv6 deployment rate. For a region where IPv6 deployment rate is low, measures may be necessary to prolong IPv4 address life for the existing business as well as for new businesses until networks are IPv6 ready. Some regions may have strong needs to secure IPv4 address space for translators. A globally coordinated policy which addresses all issues listed above (and/or others) to meet the needs for all RIR regions may result in not solving issues in any of the regions. This proposal seeks to focus on measures that should be taken globally in the address management area in order to prepare for the situation in all RIR regions. Arguments Supporting this Proposal It allows each RIR community to define a policy on how to distribute the last piece(s) of allocations which best matches their situation. Arguments Opposing this Proposal - Concerns could be raised about allocating a fixed size to all RIRs, that it artificially fastens the consumption rate of some RIR regions. However, its impact is kept to minimum by keeping the allocation size to a single /8 which makes merely 3-4 months difference. - Concerns could be raised that explicitly allowing regional policies will encourage RIR shopping. However, this should not happen if the requirements within each region is adequately reflected in each RIR's policy through PDP. RIR may also chose to add criteria to prevent LIRs from other regions submitting such requests.

Ойблинсквозь конечно же.

Кстати, а с кем в Китае можно поговорить по IPv4 transit от границы (не Российской =) ) и далее в мир? Тебе во внутрь Китая нужно или нужно пройти сквозь Китай ? Получить айпи коннективити на границе Китая и Казахстана.

Кстати, а с кем в Китае можно поговорить по IPv4 transit от границы (не Российской =) ) и далее в мир?

Белгород? :-D

Если бы дело было в Европе - поверил бы. Но не в России. В России независимость от апстрима стоит денег. И даже тех, которые стоит LIR.

Вот кстати, ОЧЕНЬ не согласен! Все совсем наоборот. Потому как PI получают те, кому нужен либо PI, либо LIR. В случае PI заявка идет на /24, /23, ну пусть /22. Или даже - о ужас! - на /21. "Тяжелые" заявки на /20 - /18 (да, и такие мы делаем тоже, причем в 100% случаев успешно) - 1-2 в месяц. В случае же LIR - сразу дается allocation /20. Внимание, вопрос: в каком случае адреса расходуются экономнее?

Зато сразу видно кто с$ет в вентилятору кого стоит шейп =)

Будете. Я тут уже вторую неделю новый аллокейшин блок получаю, чтобы соседу 8K ipv4 выдать. RIPE ревизию блоков, которые за последние полгода по aw выдавались устроил. Ха! некоторые мои запросы месяцок мурыжат типа а давайте /22 все-таки, нежели /21 =)Но я то хитрая тварь, знаю, что мурыжить-то могут, но вот реально выдать меньше права не имеют, если только сам не согласишься сдуру. Интереснее другое: Райпу в отличие от Арина не дали /8 очередные, и он вынужден выдавать сейчас только recycled блоки, которые уже были выданы кому-то, а потом отданы обратно. Почти все - в блеклистах. А других-то сетей и нет. А вы говорите ревизия блоков по aw... Так в том то и дело что уже промурыжили и аппровед. Теперь с аллокейшин мурыжат. А то!Будешь "приятно удивлен", увидя в аллокейшене знакомые цифры, ага. А поменять - нельзя. И по полиси нельзя, и не на что просто. Скажите спасибо, что это еще осталось.