Branch for alex

0.-planirovanie/0.-planirovanie.md

@@ -343,10 +343,11 @@ Hostname, IP-адрес управления, маршрут в сеть упр
 <a name="XML"></a>
 <h2>Компонент 6. Вендор-интерфейс специфичный драйвер</h2>
 Не стоит тешить себя надеждами на то, что когда-то настраивать циску можно будет точно так же, как джунипер, просто отправив на них абсолютно одинаковые вызовы. Несмотря на набирающие популярность whitebox'ы и на появление поддержки NETCONF, RESTCONF, OpenConfig, конкретный контент, который этими протоколами доставляется, отличается от вендора к вендору, и это одно из их конкурентных отличий, которое они так просто не сдадут.  
-Это примерно точно так же, как OpenContrail и OpenStack, имеющие RestAPI в качестве своего NorthBound-интерфейса, ожидают совершенно разные вызовы. 
+Это примерно точно так же, как OpenContrail и OpenStack Neutron API, имеющие RestAPI в качестве своего NorthBound-интерфейса, ожидают совершенно разные вызовы.(Сетевой сервис опенстака называется Нейтрон)
+
+Итак, на пятом шаге вендоронезависимая модель должна принять ту форму, которой максимально унифицированно и удобно можно будет описать конфгирурацию устройства без привязки к конкретной модели и конкретному интерфейсу. В дальнейшем из этой универсальной формы нам нужно как-то создать конфигурацию под конкретный случай, и здесь все средства хороши (нет): CLI, NETCONF, RESTCONF, SNMP простихоспаде.
+(зацепился глаз, навскидку кажется, чтобы мы дожны будем отправить вендор-агностик конфиг прям на железку)
 
-Итак, на пятом шаге вендоронезависимая модель должна принять ту форму, в которой она поедет на железо.  
-И здесь все средства хороши (нет): CLI, NETCONF, RESTCONF, SNMP простихоспаде.
 
 Поэтому нам понадобится драйвер, который результат предыдущего шага переложит в нужный формат конкретного вендора: набор CLI команд, структуру XML.
 
@@ -356,7 +357,7 @@ Hostname, IP-адрес управления, маршрут в сеть упр
 <hr>
 
 <a name="MAKES"></a>
-<h2>Компонент 7. Механизм доставки конфигурации на устройство</h2>
+<h2>Компонент 7. Механизм и инструмент доставки конфигурации</h2>
 Конфигурацию-то мы сгенерировали, но её ещё нужно доставить на устройства - и, очевидно, не руками.  
 <b>Во-первых</b>, перед нами тут встаёт вопрос, какой транспорт будем использовать? А выбор на сегодняшний день уже не маленький:
 <ul>

5.-interfaces/0.-history.md

@@ -71,7 +71,7 @@ CLI может быть структурированным и логичным,
 
 Ещё одна особенность CLI - отсутствие контроля состояния. CLI делает то, что ему сказали. Если ты не побеспокоился о том, чтобы удалить лишнего пира специальной командой - он и не почешется. Контроль состояния - ответственность инженера.
 
-С другой стороны CLI - это на сегодняшний день (и долго ещё так будет) единственный вариант, который на 100% современных железок позволит настроить 100% предоставляемого ими функционала. 
+С другой стороны CLI - это на сегодняшний день (и долго ещё так будет) единственный вариант, который на 100% современных железок позволит настроить 100% предоставляемой ими функциональности. 
 Учитывая, что компаний, которые сейчас строят сеть с нуля и могут выбрать только то оборудование, которое поддерживает полноценный NETCONF/gNMI, очень и очень немного, всем остальным нужно уметь поддерживать зоопарк оборудования разного возраста и уровня.
 Собственно Яндекс именно тем, что CLI работает в буквальном смысле на всём, и воспользовались. <a href="https://www.youtube.com/watch?v=cMllUl73iZg" target="_blank">Аннушка настраивает сетёвку</a> именно через CLI.
 
@@ -230,7 +230,7 @@ RPC - удивительный клиент-серверный механизм,
 Вместе они создали легендарный М40 и лучший в мире интерфейс командной строки. До сих пор никто не сделал ничего лучшего - все только повторяют.
 Операционка, предоставляющая клиенту обычный текстовый интерфейс, на самом деле перекладывает команды в XML, который используется для управления оборудованием..
 
-Так вот, их CLI и способ взаимодействия его с системой оказался настолько естественным и удачным, что его и положили в основу стандарта NETCONF в 2006-м году. Не без участия Juniper Networks, конечно же, появился <a href="https://www.ietf.org/rfc/rfc4741.txt" target="_blank">RFC4741</a>. Будем честны, один только джунипер там и постарался в практической части. И то тут, то там будут проскакивать его куски, начиная с set и заканчивая candidate config.
+Так вот, их CLI и способ взаимодействия его с системой оказался настолько естественным и удачным, что его и положили в основу стандарта NETCONF в 2006-м году. Не без участия Juniper Networks, конечно же, появился <a href="https://www.ietf.org/rfc/rfc4741.txt" target="_blank">RFC4741</a>. Будем честны, один только джунипер там и постарался в практической части. И то тут, то там будут проскакивать его куски, начиная с set и заканчивая candidate config. (спорное утверждение=/, так как параллельно развитием стандарта занимались и OSS вендоры, например шведский tail-f)
 
 Вот как он был определён в сытые нулевые:
 <blockquote>
@@ -296,10 +296,9 @@ RPC - удивительный клиент-серверный механизм,
    configurations.
 </blockquote>
 
-А через 5 лет, в  2011, исправленное и дополненное издание вышло под номером <a href="https://www.ietf.org/rfc/rfc6241.txt" target="_blank">RFC6241</a>. Там уже потрудились несколько университетов и компаний. Одной из них стала восходящая звезда сетевой автоматизации Tail-f, купленная и погубленная в 2014-м году циской.
+А через 5 лет, в  2011, исправленное и дополненное издание вышло под номером <a href="https://www.ietf.org/rfc/rfc6241.txt" target="_blank">RFC6241</a>. Там уже потрудились несколько университетов и компаний. Одной из них стала восходящая звезда сетевой автоматизации Tail-f, купленная и погубленная в 2014-м году циской.(почему погубленная, как минимум на 2017 год post-tail-f существовал как отдельный BU внутри циски)
 
-И вот в операторские сети на белом коне въезжает NETCONF.
-<ul>
+CLOUD-99973.partial<ul>
     <li>Работает по SSH.</li>
     <li>Представляет данные в структурированном виде.</li>
     <li>Разделяет конфигурационные и операционные данные.</li>
@@ -346,7 +345,7 @@ SSH - это хорошо. Но на сетевую автоматизацию 
 Это помесь RESTAPI и NETCONF, которая была призвана упростить управление сетью для WEB-приложений
 В основе лежит NETCONF, однако в качестве транспорта - HTTP с набором операций CRUD, реализованных через стандартные методы (<i>GET</i>, <i>POST</i>, <i>PUT</i>, <i>PATCH</i>, <i>DELETE</i>).
 Конфигурационные данные передаются в формате JSON или XML. 
-В качестве модели данных используется только YANG - тут уже никакой самодеятельности. 
+В качестве модели данных используется только YANG - тут уже никакой самодеятельности. (диалект для модели данных напрямую не связан с типом транспора, и способом сериализации, кмк лучше убрать это предложение)
 
 С самого начала RESTCONF не затевался как замена NETCONF, а только как более удобный для WEB-приложений способ работать с сетевыми устройствами. То есть они должны сожительствовать. 
 При этом обычно на устройстве реализуется один бэкенд, обрабатывающий запросы на работу с конфигурацией и опер.данными от разных фронотов - NETCONF или RESTCONF. То есть в основе одни и те же datastores, один и тот же движок, вычисляющий конфигурационные дельты, но сложность транзакционности и нескольких разных видов конфигураций (running, candidate, saved) от пользователя скрыта.
@@ -410,7 +409,7 @@ IETF-модель
 Ещё в 2014-м году были сделаны первые коммиты в неё https://github.com/YangModels/yang/tree/main/standard/ietf/RFC !!!
 С тех пор много накоммичено, но мало фактически сделано. Общепризнанно, что IETF -модель очень медленно развивается, у неё низкое покрытие, а схема - так себе.
 С IETF-модели рекомендуют начинать, потому что она якобы проще, а уже потом переходить на OpenConfig, но как по мне - это напрасная трата времени.
-Она мертворождённая и никому особо не нужна. Хотя вендоры поддерживают.
+Она мертворождённая и никому особо не нужна. Хотя вендоры поддерживают. (ЕМНИП OpenConfig построен вокруг IETF, но могу ошибаться)
 
 Заказчиков и пользователей беспокоили ущербность модели и инертность IETF, но один в поле не воин - тысячи разрозненных автоматизаторов по всему миру не могли ничего с этим сделать. А вот большие компании могли.
 Когда надо настроить тысячу свитчей, а каждый месяц запускать новый датацентр, когда на сети 5 разных поколений дизайна, а катить изменения нужно дважды в день, начинаешь несколько иначе смотреть на все этим ваши сиэлаи и вендор-специфичные эксэмали.
@@ -520,7 +519,7 @@ gRPC
 При этом не забываем, что на проприетарные джуносы, иосы и врп никто не притащит свой бинарничек, чтобы удобный для себя интерфейс реализовать. Это значит, что white-box коммутаторы с собственной linux OS у гугла появились задолго до того как их увидел мир. 
 Что и неудивительно - с железом они работать умеют, с Linux и подавно - дело было за малым - собрать команду Network R&D, в которой будут ребята, которые занимались разработкой своих серверов и адаптацией интерфейсов и инструментов, и найти достаточно гибкого вендора. А за последним дело не встанет, когда вы закупаете килограм свичтей в секунду.
 
-Вообще для обывателей всё началось 24 сентября 2015, когда OpenConfig consortium выпустил OpenConfig в мир. Весь FANG (кроме Amazon) поучаствовал в этом консорциуме. Но начал всю заварушку и продолжает её паровозить гугл. Естественно среди них и крупные телекомы, вроде Level3, AT&T, Verizon, Bell. 
+Вообще для обывателей всё началось 24 сентября 2015, когда OpenConfig consortium выпустил OpenConfig в мир. Весь FANG (кроме Amazon) поучаствовал в этом консорциуме. Но начал всю заварушку и продолжает её паровозить гугл. Естественно среди них и крупные телекомы, вроде Level3, AT&T, Verizon, Bell. (мб FAANG, а не FANG ?)
 
 И пока OpenConfig прокладывал себе дорогу, раскидывая в сторону вендорские и IETF модели, гугл сделал следующий шаг - как раз таки реализовал gNMI.
 
@@ -565,7 +564,7 @@ gNMI в мир пришёл под руку с OpenConfig, но неразрыв
 Day-N у кого-то решается в полностью ручном режиме, иные раскатывают обновления скриптом или простым Ansible playbook'ом, кто-то даже готовит развесистые плейбуки, основанные на модулях, "поддерживающих" состояние.
 У кого-то есть крутая CLI-автоматизация, умеющая по-настоящему поддерживать состояние.
 Самые продвинутые укладывают всё в NETCONF, собрав полноценный замкнутый цикл релиза конфигурации.
-А совсем оторванные от земли заставляют производителей поддерживать новый функционал в OpenConfig. 
+А совсем оторванные от земли заставляют производителей поддерживать новую функциональность в OpenConfig. 
 
 В целом описать всё многообразие проявлений автоматизаторской фантазии сегодня просто невозможно. Мы сейчас в мире, в котором чёрный параллелепипед ещё не был признан стандартом в области форм-фактора смартфонов.
 
@@ -689,7 +688,7 @@ Gateway навешивает сервисную метку MPLS и ещё све
 
 
 Вот вам казус: 
-Янг нацелен только на нетконф зачем?
+Янг нацелен только на нетконф зачем? // Штааа ?