Ну по сути да, с идеей выделения какого-то блока полностью согласен. Главное - не промахнуться с емкостью, чтобы потом не оказалось, что "ой, не влезли" (как это, например, произошло с кодами регионов в автомобильных номерах).
А так-то - и выделение подсетей по странам и далее по городам, соответственно, тоже очень логично и правильно было бы. Для возможности суммаризации.
По сути можно назначать любой уникальный идентификатор. Для ip-адресов просто уже существует адекватный математический аппарат и программное обеспечение, позволяющие выстроить всю логистику без изобретения новых велосипедов и расширять адресацию внутри строения. Для других идентификаторов это придется выстраивать заново и совершать марафон по граблям.
Всё это железо с посылками интерактирует только на уровне считывания штрихкодов идентификаторов отправлений, которые порождаются в почтовом отделении. С адресами они связаны только внутри ПО почты.
При небольшой емкости QR - можно печатать на конвертах пустой шаблон и просить отправителей раскрашивать нужные ячейки :) (шучу, если что, а то кто-то может серьезно воспринять).
В этом плане, конечно, ipv6 адрес удобнее, потому что эти 8 групп по 4 шестнадцатеричных символа заполнять несложно, напечатать 32 пустых поля по принципу существующих сейчас полей индекса на конверте.
У телефонистов (как и у многих других) основная проблема в сохранении обратной совместимости, чтобы это всё работало на всём том оборудовании, из которого уже построена сеть.
Почтовые же адреса - штука абсолютно виртуальная, обрабатываемая по сути исключительно программно (разве что сканеры штрих-кодов уже распространились, поэтому с ними придется обеспечивать совместимость), так что не вижу препятствий строить практически любые наложенные схемы адресации без ущерба для сервиса.
Да, а что тут нетривиального? Наложить логистический граф на базу адресов почтовых отделений и запустить над этим BGP любым уже готовым ПО - это очень простая и в абсолютно большей своей части уже решенная задача.
Мне чисто интуитивно кажется, что маршрутизация до "строения" правильнее, т.е. /64 на строение и еще остается /64 на объекты внутри строения.
А хэш даст нам, конечно, уникальные идентификаторы, но маршрутизация до них никак не простроена. Да и хэш - это хэш чего-то. И если мы хотим считать хэш от почтового адреса - то одинаковые по написанию адреса дадут нам одинаковый хэш, а стоит только отправителю написать адрес получателя в другом стиле (например, добавив пробел в каком-то условно подходящем месте) - и отправление не будет доставлено никогда. Так что идею с хэшем нужно дорабатывать.
У них всех одна проблема - они пытаются сделать структуру в системе, которая сложнее их структуры. И потом обязательно находятся исключения, которые в их структуру не ложатся.
Для машиночитаемых ресурсов достаточно сквозной уникальной нумерации без структурирования.
У меня тоже 11 Pro, основным поводом для апгрейда будет работа двух eSIM, появившаяся в 13 линейке (надеюсь, в 14 тоже сохранится). Оказалось, что в текущих условиях перевод всех тарифных планов (собственный, корпоративный + дата план в отпуске) на eSIM важен.
Ну тут надо делить на «до весны» и «после весны». Сейчас Элтекс в Энтерпрайз идёт активно. Те же PoE коммутаторы у операторов особо спросом не пользуются.
RDP - очень специфические софтовые решения, позиционируемые в некрупных сервис-провайдеров. В энтерпрайзе им особо места нет.
На них, конечно, сейчас, в условиях "дефицита всего", можно пытаться закрывать какие-то отдельные моменты в энтерпрайзных сетях, но это надо исчерпать другие опции предварительно.
Что же касается оптимистичности - в статье описан конкретный срез опыта на середину августа. Чисто теоретически можно предположить ухудшение ситуации с доступностью оборудования, но если бы пришлось ставить деньги - я бы поставил на улучшение. Потому что бабло всегда побеждает зло и большинство вендоров ищет пути возвращения на рынок тем или иным способом.
Безопасность - это прямо очень отдельный мир, там моей экспертизы не хватит.
Очень поверхностно, насколько я себе это представляю - у китайцев есть решения у DCN, но надо внимательно смотреть на функциональность. А для российских заказчиков, к сожалению, придется останавливаться на российских же решениях и тут список всем известен: Usergate, Континент, ViPNET, IDECO, Traffic Inspector.
С Fortinet вроде бы есть путь генерации лицензий, как у Cisco PLR, но врать не буду - это проходило мимо меня.
На самом деле, конечно, по-разному. Чаще всего зависит от уровня заказчика и лоббирования его интересов внутри вендора. Для условного Боинга Циска будет решать кейсы гораздо охотнее, чем для ООО «Ромашка».
Так же и с российскими вендорами - если заказчик толстый, они с большим энтузиазмом лезут в решение его проблем.
И для российских заказчиков это плюс - гораздо проще выглядеть толстым для Элтекса, чем для Циски.
Да, безусловно. Но в упомянутых мной областях они вроде бы ни на что не претендуют, а WWAN, DWDM, SDH и прочие мультиплексоры - это прямо совсем другая история. Например, тот же израильский Larch Networks сейчас специально партнерится с вьетнамскими компаниями, чтобы таким образом безопасно продавать в России. А сами напрямую выходить не хочет, опасаясь потерять доступ к американским чипсетам. Все компании очень осторожничают, поскольку потенциальный ущерб от санкций против них серьезно превышает профит работы на российском рынке.
"Курсы випассаны проводятся на пожертвования тех, кто уже их прошёл." "В центре нужно готовить еду, организовывать быт, убирать территорию. Это делают те, кто приехал служить." "Служащие медитируют три раза в день. После курса они также оставляют пожертвование."
Ну по сути да, с идеей выделения какого-то блока полностью согласен. Главное - не промахнуться с емкостью, чтобы потом не оказалось, что "ой, не влезли" (как это, например, произошло с кодами регионов в автомобильных номерах).
А так-то - и выделение подсетей по странам и далее по городам, соответственно, тоже очень логично и правильно было бы. Для возможности суммаризации.
https://habr.com/ru/post/691088/#comment_24782496
Если есть такая задача - то можно, но мне пока не очень понятно зачем.
По сути можно назначать любой уникальный идентификатор. Для ip-адресов просто уже существует адекватный математический аппарат и программное обеспечение, позволяющие выстроить всю логистику без изобретения новых велосипедов и расширять адресацию внутри строения. Для других идентификаторов это придется выстраивать заново и совершать марафон по граблям.
Всё это железо с посылками интерактирует только на уровне считывания штрихкодов идентификаторов отправлений, которые порождаются в почтовом отделении. С адресами они связаны только внутри ПО почты.
При небольшой емкости QR - можно печатать на конвертах пустой шаблон и просить отправителей раскрашивать нужные ячейки :) (шучу, если что, а то кто-то может серьезно воспринять).
В этом плане, конечно, ipv6 адрес удобнее, потому что эти 8 групп по 4 шестнадцатеричных символа заполнять несложно, напечатать 32 пустых поля по принципу существующих сейчас полей индекса на конверте.
У телефонистов (как и у многих других) основная проблема в сохранении обратной совместимости, чтобы это всё работало на всём том оборудовании, из которого уже построена сеть.
Почтовые же адреса - штука абсолютно виртуальная, обрабатываемая по сути исключительно программно (разве что сканеры штрих-кодов уже распространились, поэтому с ними придется обеспечивать совместимость), так что не вижу препятствий строить практически любые наложенные схемы адресации без ущерба для сервиса.
Там вторая половина v6 адреса остается на внутреннюю адресацию внутри строения - вряд ли кому-то не хватит 64 бит на это ;)
Да, а что тут нетривиального? Наложить логистический граф на базу адресов почтовых отделений и запустить над этим BGP любым уже готовым ПО - это очень простая и в абсолютно большей своей части уже решенная задача.
Мне чисто интуитивно кажется, что маршрутизация до "строения" правильнее, т.е. /64 на строение и еще остается /64 на объекты внутри строения.
А хэш даст нам, конечно, уникальные идентификаторы, но маршрутизация до них никак не простроена.
Да и хэш - это хэш чего-то. И если мы хотим считать хэш от почтового адреса - то одинаковые по написанию адреса дадут нам одинаковый хэш, а стоит только отправителю написать адрес получателя в другом стиле (например, добавив пробел в каком-то условно подходящем месте) - и отправление не будет доставлено никогда.
Так что идею с хэшем нужно дорабатывать.
У них всех одна проблема - они пытаются сделать структуру в системе, которая сложнее их структуры. И потом обязательно находятся исключения, которые в их структуру не ложатся.
Для машиночитаемых ресурсов достаточно сквозной уникальной нумерации без структурирования.
Надо просто каждому строению назначить префикс /64. И задача поиска пути доставки корреспонденции сведется к тривиальной :)
А почтовые адреса сохранить как исторический артефакт, не имеющий технической ценности.
У меня тоже 11 Pro, основным поводом для апгрейда будет работа двух eSIM, появившаяся в 13 линейке (надеюсь, в 14 тоже сохранится). Оказалось, что в текущих условиях перевод всех тарифных планов (собственный, корпоративный + дата план в отпуске) на eSIM важен.
Ну тут надо делить на «до весны» и «после весны». Сейчас Элтекс в Энтерпрайз идёт активно. Те же PoE коммутаторы у операторов особо спросом не пользуются.
RDP - очень специфические софтовые решения, позиционируемые в некрупных сервис-провайдеров. В энтерпрайзе им особо места нет.
На них, конечно, сейчас, в условиях "дефицита всего", можно пытаться закрывать какие-то отдельные моменты в энтерпрайзных сетях, но это надо исчерпать другие опции предварительно.
Что же касается оптимистичности - в статье описан конкретный срез опыта на середину августа. Чисто теоретически можно предположить ухудшение ситуации с доступностью оборудования, но если бы пришлось ставить деньги - я бы поставил на улучшение. Потому что бабло всегда побеждает зло и большинство вендоров ищет пути возвращения на рынок тем или иным способом.
Безопасность - это прямо очень отдельный мир, там моей экспертизы не хватит.
Очень поверхностно, насколько я себе это представляю - у китайцев есть решения у DCN, но надо внимательно смотреть на функциональность. А для российских заказчиков, к сожалению, придется останавливаться на российских же решениях и тут список всем известен: Usergate, Континент, ViPNET, IDECO, Traffic Inspector.
С Fortinet вроде бы есть путь генерации лицензий, как у Cisco PLR, но врать не буду - это проходило мимо меня.
На самом деле, конечно, по-разному. Чаще всего зависит от уровня заказчика и лоббирования его интересов внутри вендора. Для условного Боинга Циска будет решать кейсы гораздо охотнее, чем для ООО «Ромашка».
Так же и с российскими вендорами - если заказчик толстый, они с большим энтузиазмом лезут в решение его проблем.
И для российских заказчиков это плюс - гораздо проще выглядеть толстым для Элтекса, чем для Циски.
Да, безусловно. Но в упомянутых мной областях они вроде бы ни на что не претендуют, а WWAN, DWDM, SDH и прочие мультиплексоры - это прямо совсем другая история.
Например, тот же израильский Larch Networks сейчас специально партнерится с вьетнамскими компаниями, чтобы таким образом безопасно продавать в России. А сами напрямую выходить не хочет, опасаясь потерять доступ к американским чипсетам.
Все компании очень осторожничают, поскольку потенциальный ущерб от санкций против них серьезно превышает профит работы на российском рынке.
Привезти можно, но с поддержкой привезенного пока плохо. Официальный хуавей делает вид, что "это не моё".
"Курсы випассаны проводятся на пожертвования тех, кто уже их прошёл."
"В центре нужно готовить еду, организовывать быт, убирать территорию. Это делают те, кто приехал служить."
"Служащие медитируют три раза в день. После курса они также оставляют пожертвование."
Ну да, конечно.