RFC 4276 BGP-4 Implementation Report | Энциклопедия сетевых протоколов

Network Working Group                                       S. Hares
Request for Comments: 4276                                   NextHop
Category: Informational                                    A. Retana
                                                               Cisco
                                                        January 2006

Отчет о реализации протокола BGP-4

BGP-4 Implementation Report

PDF

Статус документа

Этот документ содержит информацию для сообщества Internet. Документ не задает каких-либо стандартов. Допускается свободное распространения документа.

Авторские права

Аннотация

В этом документе рассматриваются результаты опроса по реализациям протокола BGP-4. Опрос содержал 259 вопросов о реализациях, поддерживающих протокол BGP-4 в соответствии со спецификацией RFC 4271. После краткого обзора приведены все полученные отклики. Документ содержит отклики от 4 разработчиков, которые полностью ответили на вопросы (Alcatel, Cisco, Laurel и NextHop), а также краткую информацию от 3 других разработчиков (Avici, Data Connection Ltd. и Nokia).

Редакторы не использовали дополнительных источников для проверки корректности сведений, представленных в откликах. Респонденты являются экспертами по продукции, которой касался опрос.

1. Введение

В этом документе рассматриваются результаты опроса по реализациям протокола BGP-4. RFC 4271 приведен в соответствие с текущей установленной базой BGP-4 и отменяет действие [RFC1771]. Протокол BGP является широко распространенным протоколом, являющимся основой технологии Internet и добавляющим новые функции по мере необходимости в процессе развития Internet. В современной сети Internet протокол BGP-4 включает как базовую спецификацию, так и множество дополнительных спецификаций, таких, как TCP MD5 [RFC2385], BGP Route Reflectors [RFC2796], BGP Confederations [RFC3065] и BGP Route Refresh [RFC2918].

Опрос о реализациях BGP содержал 259 вопросов о соответствии спецификации RFC 4271. Четыре разработчика (Alcatel, Cisco, Laurel и NextHop) полностью ответили на вопросы. Результаты обработки этих ответов приведены в главе 3.

В параграфе 2.1 рассматриваются существенные различия между реализациями, а параграф 2.2 содержит обзор различий между реализациями этих 4 компаний. В параграфе 2.3 обсуждаются вопросы интероперабельности.

Вследствие большого числа реализаций BGP и малого количества респондентов редакторы провели неформальный опрос по поводу размера исходного опроса. Трое из участников неформально опроса указали, что слишком большое количество вопросов не позволило им дать свой отклик. Результаты неформального опроса приведены в главе 4. В этот документ редакторы включили результаты как формального опроса о реализациях протокола, так и неформального опроса.

1.1. Используемые соглашения

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с RFC 2119 [RFC2119].

2. Результаты опроса

Респонденты должны были ответить Y (да) или N (нет) на 259 вопросов, чтобы показать, насколько их реализация поддерживает функции/описание в терминах [RFC2119] требований спецификации [RFC4271].

Респонденты могли указать ответ O (иное) для индикации ответов, которые не могли трактоваться как Y или N (например, альтернативный вариант поведения).

2.1. Значимые различия

Каждый вопрос, на который было получено не менее двух неотрицательных ответов (т. е., два Y или Y и O), за исключением следующих вопросов:

необходимо – связанные вопросы 212 и 213, относящиеся к параграфу 9.1.4

Из-за принятого формата связанных вопросов три производителя (Cisco, Laurel и NextHop) ответили N на вопрос 213 (подробности приведены в параграфе 2.2).
не следует – вопрос 228, относящийся к параграфу 9.2.2.2

Три производителя (Alcatel, Cisco и Laurel) ответили N для не следует (означает, что они делают это). Один производитель (NextHop) указал O, что соответствует спецификации.

Текст: Маршруты с разными атрибутами MULTI_EXIT_DISC не следует агрегировать (параграф 9.2.2.2, [RFC4271])
следует – вопросы 257 и 258, относящиеся к Приложению F

Три производителя ответили N и один – Y на вопрос 257. Все 4 производителя ответили N на вопрос 258 (отметим, что поддержка Приложения F Рекомендации для разработчиков не является обязательной.)

Текст¹: Во избежание ненужных осцилляций маршрутов (route flapping) узлу BGP, которому нужно отозвать адресата и передать обновление с более (или менее) специфичным маршрутом, следует объединять анонсы в одно сообщение UPDATE. (Приложение F.2, [RFC4271])

Текст: Последний (самый правый) экземпляр данного номера AS сохраняется. (Приложение F.6, [RFC4271])
возможно – вопросы 180 и 254, относящиеся к параграфу 8.2.1.4² и главе 10

Три производителя ответили N и один – Y на вопрос 180.

Текст: Номера событий (1-28) используются при описании машины состояний. Реализации могут использовать эти номера для систем сетевого управления. Точная форма FSM или событий FSM зависит от реализации. (параграф 8.2.1.4, [RFC4271])

Примечание редактора: Параграф 8.2.1.4 был включен для того, чтобы позволить существующим реализациям перейти к новой нумерации событий. Предполагается, что по прошествии времени (3 года) нумерация событий FSM будет заменена на новую.

На вопрос 254 о настройке значений параметра флуктуации³ три производителя ответили N и один Y.

Текст: Данный узел BGP может использовать одинаковые флуктуации для каждого из этих таймеров независимо от адресатов передаваемых обновлений (т. е., флуктуации не требуется делать независимыми для каждого партнера). (глава 10, [RFC4271])

Вопрос: Является ли диапазон флуктуаций настраиваемым?

2.2. Обзор отличий

В этом параграфе дается обзор отличий между 4 реализациями протокола.

На перечисленные ниже вопросы не было получено ответа Y ни от одного из 4 респондентов. Отметим, что номера вопросов соответствуют последней части номера параграфов в главе 3.

необходимо

97, 106, 107, 111, 122, 125, 138, 141, 213

нужно

233, 239

не следует

228

следует

42, 117, 132, 146, 152, 155, 156, 157, 158, 159, 160, 161, 163, 164, 165, 169, 170, 171, 173, 174, 175, 202, 225, 250, 255, 256

не нужно

226

возможно

67, 94, 121, 143, 180, 223, 247, 254

Прочее

236, 238

Связанные вопросы

212/213

Три производителя ответили N и один – Y на вопрос 213 об агрегировании маршрутов. Вопросы 212 и 213 были объединены в один.

Вопрос 212: «процесс выбора должен установить в Loc-RIB оба маршрута или …»

Вопрос 213: «объединить их и установить в Loc-RIB агрегированный маршрут, что обеспечивается наличием в обоих маршрутах одинакового значения атрибута NEXT_HOP»

Четыре респондента ответили Y на вопрос 212, три сказали N в ответ на вопрос 213. В контексте вопроса ответ N на вопрос 213 является допустимым.

2.3. Взаимодействие реализаций

	Alcatel	Cisco	Laurel	NextHop
Alcatel	+	+
Cisco		+
Laurel		+	+
NextHop		+		+

2.4. Идентификация реализаций BGP

1.6.0 Alcatel

Разработчик/версия: Alcatel 7750 BGP Implementation Release 1.3

Дата: июль 2003

Контактное лицо: Devendra Raut

Электронная почта: Devendra.raut@Alcatel.com

1.6.1 Cisco

Разработчик/версия: Cisco BGP Implementation, 12.0(27)S

Контактное лицо: Alvaro Retana

Дата: 26 ноября 2003

1.6.2 Laurel

Разработчик/версия: Laurel Networks 3.0

Контактное лицо: Manish Vora

Электронная почта: vora@laurelnetworks.com

Дата: 1 февраля 2004

1.6.3 NextHop Technologies

Разработчик/версия: Gated NGC 2.0, 2.2

Дата: январь 2004

3. Отчет о реализациях BGP-4

Для каждого из перечисленных элементов респонденты указывали поддерживает ли их реализация Функции/описание (Y/N) согласно спецификации требований [RFC2119]. Все комментарии респондентов приведены в тексте. В некоторых случаях респонденты давали ответ O (иное), показывающий, что варианты Y/N не подходят (например, альтернативный вариант поведения). Для лучшего понимания указаны ссылки на соответствующие разделы спецификации [RFC4271]. Отметим, что последняя часть номера параграфа в этой главе совпадает с номером вопроса.

3.0. Основы работы протокола, глава 3 [RFC4271]

3.0.1. Базовое поведение

Функции/описание: Совместима ли ваша реализация с базовым поведением протокола, описанным в этой главе?

RFC2119: N/A

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.0.2. Локальное изменение политики

Функции/описание: Чтобы позволить активизацию изменений локальной политики без сброса соединений BGP, узлу BGP следует (a) сохранить текущую версию маршрутов, анонсированных всеми партнерами в течение сеанса или (b) использовать расширение Route Refresh [RFC2918]

3.2.5. Базы маршрутной информации

Функции/описание: Совместима ли ваша реализация со структурой RIB, описанной в этом параграфе?

RFC2119: N/A

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.2.6. Преобразование Next Hop

Функции/описание: Значение следующего интервала (next hop) для каждого из маршрутов таблицы Loc-RIB должно быть преобразуемым с помощью локальной таблицы маршрутизации узла BGP.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.3. Формат сообщений, глава 4 [RFC4271]

3.3.7. Размер сообщений

Функции/описание: Поддерживает ли ваше реализация размеры сообщений, указанные в этой главе?

3.5.12. Расчет значения Hold Timer

Функции/описание: Использование меньшего из двух значений Hold Time – заданного в параметрах конфигурации и полученного в сообщении OPEN.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.5.13. Минимальное значение Hold Time

Функции/описание: Значение этого параметра должно быть нулевым или не менее трех секунд.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.5.14. Отказ от приема соединения

Функции/описание: На основе Hold Time

3.7.26. Максимальная частота передачи KEEPALIVE

Функции/описание: Недопустимо передавать более одного сообщения в секунду.

RFC2119: MUST NOT (недопустимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.7.27. Частота передачи сообщений KEEPALIVE

Функции/описание: Задается как функция интервала Hold Time.

RFC2119: MAY (возможно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.7.28. Согласование нулевого значения Hold Time

Функции/описание: Сообщения KEEPALIVE не передаются

RFC2119: MUST NOT (недопустимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.8. Формат сообщения NOTIFICATION, параграф 4.5 [RFC4271]

3.8.29. Сообщение NOTIFICATION

Функции/описание: Поддерживает ли ваша реализация сообщения NOTIFICATION, описанные в этом параграфе?

3.10.45. ORIGIN

Функции/описание: Значение не следует изменять никакому узлу за исключением исходного (originator).

3.17.81. Обработка ошибок

Функции/описание: Совместима ли ваша реализация с процедурами обработки ошибок, описанными в этой главе?

RFC2119: N/A

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.17.82. Субкод ошибки

Функции/описание: Считается нулевым, если не указан.

Функции/описание: Для субкода ошибки должно указываться значение 0 (Unspecific – не задан).

3.21.132. Ошибка в сообщении NOTIFICATION

Функции/описание: Отмечена, отражена в локальном журнале, информация передана также администратору партнера.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: N

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.22. Обработка ошибок Hold Timer Expired, параграф 6.5 [RFC4271]

3.22.133. Hold Timer Expired

Функции/описание: Совместима ли ваша реализация с процедурами обработки ошибок, описанными в этом параграфе?

3.25.140. Конфликт соединений

Функции/описание: Одно из соединений должно быть закрыто.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.25.141. Получение сообщения OPEN

Функции/описание: Локальная система должна проверить все свои соединения, находящиеся в состоянии OpenConfirm.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: O Мы детектируем конфликты своим способом и метод разрешения конфликтов описан в документации.

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.25.142. Получение сообщения OPEN

Функции/описание: Проверка соединений, находящихся в состоянии OpenSent, если известно значение BGP Identifier из внешних (по отношению к протоколу) источников.

3.27.145. FSM

Функции/описание: Совместима ли ваша реализация с концептуальной моделью FSM, описанной в этой главе?

3.32.176. FSM

Функции/описание: Раздельная машина FSM для каждого указанного в конфигурации партнера.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.32.177. TCP Port 179

Функции/описание: Реализация BGP должна подключаться и прослушивать порт TCP 179 в дополнение к попыткам организации соединения с партнерами.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.32.178. Входящие соединения

Функции/описание: машина состояний должна поддерживать множество экземпляров.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.33. FSM и детектирование конфликтов, параграф 8.2.1.2 [RFC4271]

3.33.179. Конфликт соединений

Функции/описание: Машину FSM для закрываемого соединения следует отключать.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.34. Номера событий FSM, параграф 8.2.1.4 [RFC4271]

3.34.180. Номера событий

Функции/описание: Используются для обеспечения данных сетевого управления.

RFC2119: MAY (возможно)

Alcatel Y/N/O/комментарии: Y Недоступны для оператора.

Cisco Y/N/O/комментарии: N

Laurel Y/N/O/комментарии: N

NextHop Y/N/O/комментарии: N Будущие версии GateD NGC могут поддерживать номера событий.

3.35. Машина конечных состояний, параграф 8.2.2 [RFC4271]

3.35.181. ConnectRetryTimer

Функции/описание: Значение должно быть достаточно большим, чтобы позволить инициализацию TCP.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.35.182. Отслеживание двойных соединений

Функции/описание: В ответ на успешную организацию соединения TCP [Событие 16 или 17] второе соединение нужно отслеживать до тех пор, пока через него не будет передано сообщение OPEN.

3.37.189. Процесс выбора маршрутов⁶

Функции/описание: Совместима ли ваша реализация с требованиями этого параграфа?

RFC2119: N/A

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.37.190. Уровень предпочтения

Функции/описание: Не следует использовать в качестве входных данных перечисленные здесь: существование других маршрутов, отсутствие других маршрутов или атрибуты пути других маршрутов.

3.40.200. Непреобразуемые маршруты

Функции/описание: Исключаются из Фазы 2 при выборе маршрутов.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.40.201. Множество подходящих маршрутов

Функции/описание: Следует рассматривать только маршрут с наибольшей длиной соответствия.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.40.202. Взаимная рекурсия

Функции/описание: Если маршрут не проходит проверку на преобразуемость вследствие взаимной рекурсии, сообщение об ошибке следует записать в системный журнал.

3.42.208. Правила обработки маршрутов из Loc-RIB, передаваемых в Adj-RIBs-Out

Функции/описание: Маршруты из Loc-RIB могут не добавляться в ту или иную базу Adj-RIB-Out.

RFC2119: MAY (возможно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.42.209. Установка маршрута в Adj-Rib-Out

Функции/описание: Маршрут не следует устанавливать в Adj-Rib-Out, если для адресатов и NEXT_HOP этого маршрута а таблице маршрутизации нет соответствующей записи.

RFC2119: SHALL NOT (не следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.42.210. Отзываемые маршруты

Функции/описание: Если маршрут из базы Loc-RIB не включается в ту или иную базу Adj-RIB-Out, ранее анонсированный маршрут этой базы Adj-RIB-Out должен быть отозван с помощью сообщения UPDATE (см. параграф 9.2).

NextHop Y/N/O/комментарии: Y

3.47.243. Нестабильные маршруты

Функции/описание: Избегать использования таких маршрутов.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.47.244. Изменения маршрутов

Функции/описание: Не следует принимать быстрых спонтанных решений об изменении при выборе маршрутов.

3.50.255. Поддержка TCP PUSH

Функции/описание: Каждое сообщение BGP следует передавать с установленным флагом PUSH.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: O В зависимости от возможностей стека TCP. GateD 10, NGC может работать с различными вариантами стека протоколов.

Функции/описание: Реализация BGP должна поддерживать механизм аутентификации, описанный в RFC 2385 [RFC2385].

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

4. Дополнительные сведения о реализациях BGP

Три разработчика ответили по телефону (в период с 20.05.2004 по 02.06.2004) и сообщили, что у них имеются реализации BGP, но они не ответили полностью на вопросы “анкеты”. Полученная от этих разработчиков информация представлена ниже.

4.1. Avici

Если у вас есть реализация BGP, но вы не отправили отчет о ней (ответы на 259 вопросов), не могли бы вы прислать мне ответы на следующие вопросы:

1) Продукция BGP

Разработчик (ваше имя): Curtis Villamizar [curtis@fictitious.org]

Компания: Avici

Название продукции: IPriori (TM)

Младшая версия: не возникает проблем интероперабельности при работе с любой версией.

В настоящее время реализованы версии 5.x и 6.0.x. Версия 6.1 и последующие будут тестироваться на предмет соответствия последней спецификации BGP [RFC4271].

2) С какими реализациями может совместно работать ваша?

Cisco: IOS 12.0(22)

Juniper: JUNOS (версия не указана)

3) Обеспечивает ли ваша реализация интероперабельность с:

1) Alcatel BGP (release) – не тестировалась

2) cisco BGP IOS 12.0(27)s – не тестировалась; тестировалась с IOS 12.0(22); BGP в этих версиях не различается.

3) laurel BGP (specify release) – не тестировалась

4) NextHop GateD – не тестировалась

4) Количество вопросов анкеты BGP послужило причиной того, что вы не отправили отчет о своей реализации BGP?

Да

4.2. Data Connection Ltd.

1) Продукция BGP

Разработчик (ваше имя): Mike Dell

Компания: Data Connection Ltd.

Название продукции: DC-BGP

Версия: v1.1

Дата выпуска: апрель 2003

2) С какими реализациями может совместно работать ваша?

Cisco (12.0(26)S)

Alcatal (7770 0BX)

Agilent (Router Tester)

Ixia (1600T)

Netplane (Powercode)

Nortel (Shasta 5000 BSN)

Redback (SmartEdge 800)

Riverstone (RS8000)

Spirent (AX4000)

IP Infusion (ZebOs)

Nokia (IP400)

Juniper (M5)

3) Обеспечивает ли ваша реализация интероперабельность с:

1) Alcatel BGP (release) – Да

2) cisco BGP IOS 12.0(27)s – Неизвестно, но мы можем работать совместно с v12.0(26)s

3) laurel BGP (specify release) – Неизвестно

4) NextHop GateD – Да

4) Количество вопросов анкеты BGP послужило причиной того, что вы не отправили отчет о своей реализации BGP?

Да

4.3. Nokia

1) Продукция BGP

Разработчик (ваше имя): Rahul Bahadur (rahul.bahadur@nokia.com)

Компания: Nokia

Название продукции: платформы IP Security

Версия: IPSO 3.8 Build031

Дата выпуска: 24 мая 2004

2) С какими реализациями может совместно работать ваша?

Cisco: IOS 12.3(1)

Extreme: Extremeware Version 6.1.7 (Build 9)

Foundry: SW Version 07.5.05iT53

Juniper: JUNOS 5.3R1.2

Nortel: BayRS 15.4.0.1

GNU Zebra: zebra-0.92a

3) Обеспечивает ли ваша реализация интероперабельность с:

1) Alcatel BGP (release) – не тестировалась

2) cisco BGP IOS 12.0(27)s – да

3) laurel BGP (specify release) – не тестировалась

4) NextHop GateD – не тестировалась

4) Количество вопросов анкеты BGP послужило причиной того, что вы не отправили отчет о своей реализации BGP?

Да – нехватка ресурсов для выполнения этой задачи.

5. Вопросы безопасности

В этом документе не рассматриваются какие-либо вопросы безопасности.

6. Нормативные документы

[RFC4271] Rekhter, Y., Li, T., and S. Hares, Eds., “A Border Gateway Protocol 4 (BGP-4)”, RFC 4271, January 2006.

[RFC1771] Rekhter, Y. and T. Li, “A Border Gateway Protocol 4 (BGP-4)”, RFC 1771, March 1995.

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

[RFC2385] Heffernan, A., “Protection of BGP Sessions via the TCP MD5 Signature Option”, RFC 2385, August 1998.

[RFC2796] Bates, T., Chandra, R., and E. Chen, “BGP Route Reflection – An Alternative to Full Mesh IBGP”, RFC 2796, April 2000.

[RFC2918] Chen, E., “Route Refresh Capability for BGP-4”, RFC 2918, September 2000.

[RFC3065] Traina, P., McPherson, D., and J. Scudder, “Autonomous System Confederations for BGP”, RFC 3065, February 2001.

7. Благодарности

Отклики Alcatel были представлены:

Contact Name: Devendra Raut

Contact EMail: Devendra.raut@Alcatel.com

Отклики Cisco Systems были представлены:

Contact Name: Himanshu Shah, Ruchi Kapoor

Contact EMail: hhshah@cisco.com, ruchi@cisco.com

Отклики Laurel были представлены:

Contact Name: Manish Vora

Contact EMail: vora@laurelnetworks.com

Отклики NextHop были представлены:

Contact Name: Susan Hares

Contact EMail: skh@nexthop.com

Additional Help: Matt Richardson, Shane Wright.

Адреса авторов

Susan Hares

NextHop Technologies

825 Victors Way, Suite 100

Ann Arbor, MI 48108

Phone: 734.222.1610

EMail: skh@nexthop.com

Alvaro Retana

Cisco Systems, Inc.

7025 Kit Creek Rd.

Research Triangle Park, NC 27709

Phone: 919 392 2061

EMail: aretana@cisco.com

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

Полное заявление авторских прав

К этому документу применимы права, лицензии и ограничения, указанные в BCP 78, и, за исключением указанного там, авторы сохраняют свои права.

Этот документ и содержащаяся в нем информация представлены “как есть” и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.

Интеллектуальная собственность

IETF не принимает какой-либо позиции в отношении действительности или объема каких-либо прав интеллектуальной собственности (Intellectual Property Rights или IPR) или иных прав, которые, как может быть заявлено, относятся к реализации или использованию описанной в этом документе технологии, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах IETF в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.

Копии раскрытия IPR, предоставленные секретариату IETF, и любые гарантии доступности лицензий, а также результаты попыток получить общую лицензию или право на использование таких прав собственности разработчиками или пользователями этой спецификации, можно получить из сетевого репозитория IETF IPR по ссылке http://www.ietf.org/ipr.

IETF предлагает любой заинтересованной стороне обратить внимание на авторские права, патенты или использование патентов, а также иные права собственности, которые могут потребоваться для реализации этого стандарта. Информацию следует направлять в IETF по адресу ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено IETF Administrative Support Activity (IASA).

1Здесь и далее тексты RFC 4271 приводятся из перевода спецификации протокола, опубликованного на сайте. Прим. перев.

2В оригинале ошибочно указан параграф 8.1.2.4. Прим. перев.

3Jitter time.

4См. предыдущий параграф. Прим. перев.

5Finite State Machine – машина конечных состояний.

6Decision Process

7Differentiated Services Code Point