Internet Engineering Task Force (IETF) J. Haas Request for Comments: 9384 Juniper Networks Category: Standards Track March 2023 ISSN: 2070-1721
A BGP Cease NOTIFICATION Subcode for Bidirectional Forwarding Detection (BFD)
Субкод уведомления BGP Cease для BFD
Аннотация
Протокол обнаружения двухсторонней пересылки (Bidirectional Forwarding Detection или BFD, RFC 5880) служит для обнаружения потери связности между двумя машинами (узлами) пересылки, обычно с малой задержкой. BFD применяется протоколами маршрутизации, включая протокол граничного шлюза (Border Gateway Protocol или BGP), для более быстрого отключения (down) соединений протокола по сравнению с обычными протокольными таймерами.
Этот документ задаёт субкод сообщения BGP Cease NOTIFICATION (параграф 6.7 в RFC 4271) для использования при разрыве соединения BGP в результате закрытия сессии BFD.
Статус документа
Документ относится к категории Internet Standards Track.
Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.
Информация о текущем статусе документа, найденных ошибках и способах обратной связи доступна по ссылке https://www.rfc-editor.org/info/rfc9384.
Авторские права
Copyright (c) 2023. Авторские права принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.
К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).
1. Введение
Протокол BFD [RFC5880] применяется для обнаружения потери связности между двумя узлами пересылки, обычно с малой задержкой. BFD используется как служба для разных клиентов, включая протоколы маршрутизации, чтобы предоставить этим клиентам механизм рекомендаций по выполнению подобающих действий при отключении (down) сессии BFD [RFC5882]. Это обычно применяется клиентами для инициирования более быстрого закрытия соединений, нежели могут обеспечить таймеры протоколов.
Протокол BGP версии 4 (BGP-4) [RFC4271] разрывает соединения по таймеру удержания (Hold Timer), когда узел не получает сообщений BGP в течение согласованного интервала Hold Time. В соответствии с параграфами 4.2 и 4.4 [RFC4271], минимальное значение Hold Time составляет не менее 3 секунд, если только обработка KEEPALIVE не была отключена согласованием нулевого значения Hold Time.
Если узел BGP хочет при потере связности разрывать соединения быстрее, нежели позволяет согласованный BGP Hold Timer, он может воспользоваться протоколом BFD для более быстрого обнаружения прерывания связности узлами BGP. Когда состояние сессии BFD меняется на Down, узел BGP разрывает соединение с помощью сообщения Cease NOTIFICATION, передаваемого соседу, и, если это возможно, разрывает соединение TCP для сессии.
Этот документ определяет для передачи в сообщении Cease NOTIFICATION субкод BFD Down, указывающий эту причину разрыва соединения.
2. Уровни требований
Ключевые слова должно (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.
3. Субкод BFD Cease NOTIFICATION
Для субкода BFD Down сообщений Cease NOTIFICATION агентство IANA выделило значение 10.
При разрыве соединения BGP по переходу сессии BFD в состояние Down узлу BGP следует передать сообщение NOTIFICATION с кодом ошибки Cease и субкодом BFD Down.
4. Эксплуатационные вопросы
Сессия BFD может перейти в состояние Down при частичной потере связности между двумя узлами BGP. Операторы, применяющие BFD для своих соединений BGP, могут выбирать значения для таймеров BFD на основе разных критериев, например, стабильности и скорости обнаружения отказов.
При разрыве соединения BGP по событию BFD Down в результате обнаруженной BFD частичной потери связности, удалённый узел BGP может получить сообщение BGP Cease NOTIFICATION с субкодом BFD Down. После этого принявший сообщение узел BGP будет понимать, что соединение разрывается из-за проблемы, обнаруженной BFD, а не из-за проблемы на узле BGP.
В случае полной потери связности между двумя узлами BGP отправка сообщения Cease NOTIFICATION может оказаться невозможной. Тем не менее, узлам BGP следует указать эту причину как часть своего рабочего состояния. Примеры включают bgpPeerLastError в соответствии с BGP MIB [RFC4273] и last-error в [BGP-YANG].
Когда требуются процедуры из [RFC8538] для отправки сообщения NOTIFICATION с кодом ошибки Cease и субкодом Hard Reset, а соединение разрывается по причине перехода BFD в состояние Down, следует инкапсулировать субкод BFD Down в данные Hard Reset сообщения NOTIFICATION.
5. Вопросы безопасности
Подобно [RFC4486], этот документ задаёт субкод для сообщений BGP Cease NOTIFICATION, предоставляющий сведения, которые помогают оператору сети сопоставить события в сети и диагностировать проблемы партнёрства BGP. Этот субкод является чисто информационным и не влияет на конечный автомат BGP (Finite State Machine) сверх указанного в параграфах 6.6 и 6.7 [RFC4271].
6. Взаимодействие с IANA
Агентство IANA выбелило значение 10 в реестре BGP Cease NOTIFICATION message subcodes (https://www.iana.org/assignments/bgp-parameters/) с именем BFD Down и ссылкой на этот документ.
7. Литература
7.1. Нормативные документы
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., “A Border Gateway Protocol 4 (BGP-4)”, RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.
[RFC5880] Katz, D. and D. Ward, “Bidirectional Forwarding Detection (BFD)”, RFC 5880, DOI 10.17487/RFC5880, June 2010, <https://www.rfc-editor.org/info/rfc5880>.
[RFC5882] Katz, D. and D. Ward, “Generic Application of Bidirectional Forwarding Detection (BFD)”, RFC 5882, DOI 10.17487/RFC5882, June 2010, <https://www.rfc-editor.org/info/rfc5882>.
[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8538] Patel, K., Fernando, R., Scudder, J., and J. Haas, “Notification Message Support for BGP Graceful Restart”, RFC 8538, DOI 10.17487/RFC8538, March 2019, <https://www.rfc-editor.org/info/rfc8538>.
7.2. Дополнительная литература
[BGP-YANG] Jethanandani, M., Patel, K., Hares, S., and J. Haas, “YANG Model for Border Gateway Protocol (BGP-4)”, Work in Progress, Internet-Draft, draft-ietf-idr-bgp-model-16, 1 March 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-16>.
[RFC4273] Haas, J., Ed. and S. Hares, Ed., “Definitions of Managed Objects for BGP-4”, RFC 4273, DOI 10.17487/RFC4273, January 2006, <https://www.rfc-editor.org/info/rfc4273>.
[RFC4486] Chen, E. and V. Gillet, “Subcodes for BGP Cease Notification Message”, RFC 4486, DOI 10.17487/RFC4486, April 2006, <https://www.rfc-editor.org/info/rfc4486>.
Благодарности
Спасибо Jeff Tantsura и Dale Carder за их комментарии к этому документу.
Mohamed Boucadair предоставил отзыв на документ в рамках обзора Routing Directorate.
В 2006 г. Bruno Rijsman подготовил предложение, по сути похожее на этот документ, – draft-rijsman-bfd-down-subcode. В тот момент документ не прошёл в рабочей группе междоменной маршрутизации (Inter-Domain Routing или IDR). Автор этого документа не знал о работе Bruno при подготовке своего предложения.
Адрес автора
Jeffrey Haas Juniper Networks Email: jhaas@juniper.netПеревод на русский язык
Николай Малых
1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.
2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.