Не смотря на весь хайп, но при этом действительно неплохие возможности, у Segment Routing очень много проблем для того чтобы избавить мир от нелюбимого (большинством) RSVP-TE прямо сейчас. Самые банальные и одновременно серьёзные из них все и так знают. Редко встретишь историю о TI-LFA.
Из каждого утюга доносится: SR поддерживает замечательный механизм FRR, он значительно превосходит своих IP FRR побратимов, и даже RSVP-TE FRR ему уступает, то в том, то в этом. И почти никто не говорит, что хорошо TI-LFA работает только в контексте SR, который сам по себе закрывает достаточно обширную нишу, но при этом не является тем, ради чего мы все сегодня собрались. Гораздо более важный груз ответственности лежит на SR-TE, без которого о какой-либо замене RSVP-TE говорить не приходится. И тут возникает один нюанс, который редко встретишь в евангелистских докладах.
У TI-LFA есть определённые сложности в работе с SR-TE. Так как весь LSP закодирован в пакете, опираясь на основной принцип работы MPLS, PLR может принимать решения о защите LSP имея на руках только метку на вершине стэка. Это первое фундаментальное отличие от RSVP-TE, в котором благодаря сообщениям Path каждый LSR в рамках LSP знает его endpoint. В SR же под защиту подпадает не весь LSP, а только лишь конкретная метка в конкретный момент времени и это второе отличие от RSVP-TE. Третье же отличие состоит в том, что в рамках SR метка имеет определённую семантику, — Node SID, adjacency SID, etc. — которая доступна благодаря единой LSDB.
На минутку прервёмся и вспомним, как работает TI-LFA. Если очень коротко, то данный механизм исключает из топологии рёбра и/или вершины, которые гипотетически вышли из строя, и запускает по ней SPF. При этом сохраняются все свойства LFA, что обеспечивается (в случае необходимости) добавлением рулевых меток в стэк, чтобы не нарваться на петли. Сильной стороной этого механизма является то, что по факту новый SPT будет соответствовать тому, который IGP пересчитает в случае реальной аварии, отсюда и TI.
Для тех, кто не был знаком с проблематикой, на данном моменте всё должно было стать очевидным. Если в стэке меток содержатся Node SID, которые вышли из строя, или adjacency SID по направлению к ним, TI-LFA не сможет рассчитать резервный путь. Да, от банальной поломки интерфейса защититься возможно, если есть дополнительные, но node protection невозможен.
Существует черновик стандарта (наверное, самая популярная фраза на этом канале), в котором подробно описана проблема и предлагаемый способ её решения (draft-hegde-spring-node-protection-for-sr-te-paths). Суть его состоит в том, чтобы для каждого соседнего LSR по пути LSP в специальной таблице PLR сохранял метки и действия для них от лица этого LSR. То есть необходимо хранить не только свои метки, но ещё и за соседа посчитать и сохранить результат в его контексте меток (здесь нам снова потребуется RFC 5331). А нужно это для того, чтобы по метке, которую сосед использовал бы для передачи трафика, определить next-next-hop LSR. Расписываю я это всё затем, чтобы сделать прозрачный намёк на то, как элегантная и где-то даже простая технология начинает потихоньку обрастать монструозными конструкциями, призванными закрыть её недостатки (и создать новые). А так уж ли плох RSVP-TE?
