а если быть точнее, при разборе типов маршрутов, возник вопрос: зачем разработчики ввели отдельный тип маршрута (type 4), предназначенный для выборов DF среди multi-homing маршрутизаторов? Вопрос звучит достаточно странно, но подумайте вот о чём: каждый mh PE так же обязан анонсировать маршрут type 1 (A-D per ES). И мне кажется, сумма того, что каждый PE, подключенный к mh ES, анонсирует его, и того, что назначение этого маршрута — auto discovery, дают в сумме ровно тот же эффект, что и наличие выделенного типа маршрута номер 4. Да, в type 1 нет поля Originator ID, на котором основана процедура выборов DF, но его можно было добавить. Да, type 4 «скрыт» от остальных PE благодаря специальной ES-Import RT, но это больше похоже на «патч», нежели на серьёзное решение, который бы и не потребовался, если бы выборы DF возложили на type 1 per ES.
Единственный, кто эксплуатирует подобную декомпозицию, это PBB, в котором type 1 маршруты не требуются ни в каком виде, но multi-homing поддерживается, и DF необходим, как и type 4. Но вряд ли это и была основная причина, а может быть её и не было вовсе?
Так как точного ответа у меня нет, могу предположить только лишь, что разработчики заранее разделили задачи с некоторым залогом под потенциальные коррективы в процедуре выборов DF. Текущий механизм выборов сильно критикуется сообществом, существует несколько драфтов, предлагающих внести в него изменения, с описанием текущих недостатков и процедурами интеграции с текущими реализациями. И если, например, в type 1 и можно было просто добавить поле Originator ID, то возложить какие-то более сложные роли уже, возможно, труднее. В общем, ворону — вороново.
прочитал. Бесполезная болтовня какая-то. Итога нет, просто рассуждение
Обсуждают сегодня