RFC 4276
BGP-4 Implementation Report
BGP-4 Implementation Report 🦋
Okay bestie, let's start with the basics 💅 This is RFC 4276, called BGP-4 Implementation Report, from the Network Working Group. The authors are S. Hares (NextHop) and A. Retana (Cisco). It's labelled Category: Informational and it's dated January 2006. The header doesn't list any Obsoletes or Updates, so this one doesn't replace or change another document 🌸
Status of This Memo
Real talk, this memo just provides information for the Internet community ✨ It does not specify an Internet standard of any kind, and distribution of it is unlimited 🎀
Copyright Notice
Copyright (C) The Internet Society (2006) 📜
Abstract
Okay so this doc reports the results of the BGP-4 implementation survey 📊 The survey had 259 questions about how well implementations support BGP-4, which is specified in RFC 4271. After a quick summary of the results, every response gets listed 💖
Four implementers finished the survey: Alcatel, Cisco, Laurel, and NextHop 🫶 Three more didn't finish it, but still gave brief info: Avici, Data Connection Ltd., and Nokia 🦋
The editors didn't use any outside sources to check the accuracy of what people submitted. But honestly? The respondents are experts with the products they reported on, so they're literally the people to ask 👑
Table of Contents
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. Results of Survey ...............................................4
2.1. Significant Differences ....................................4
2.2. Overview of Differences ....................................5
2.3. Implementations and Interoperability .......................6
2.4. BGP Implementation Identification ..........................7
3. BGP-4 Implementation Report .....................................7
3.0. Summary of Operation / Section 3 [RFC4271] .................7
3.1. Routes: Advertisement and Storage / Section 3.1 [RFC4271] ..8
3.2. Routing Information Bases / Section 3.2 [RFC4271] ..........9
3.3. Message Formats / Section 4 [RFC4271] ......................9
3.4. Message Header Format / Section 4.1 [RFC4271] .............10
3.5. OPEN Message / Section 4.2 [RFC4271] ......................11
3.6. UPDATE Message Format / Section 4.3 [RFC4271] .............12
3.7. KEEPALIVE Message Format / Section 4.4 [RFC4271] ..........16
3.8. NOTIFICATION Message Format / Section 4.5 [RFC4271] .......17
3.9. Path Attributes /Section 5 [RFC4271] ......................17
3.10. ORIGIN / Section 5.1.1 [RFC4271] .........................22
3.11. AS_PATH / Section 5.1.2 [RFC4271] ........................22
3.12. NEXT_HOP / Section 5.1.3 [RFC4271] .......................23
3.13. MULTI_EXIT_DISC / Section 5.1.4 [RFC4271] ................27
3.14. LOCAL_PREF / Section 5.1.5 [RFC4271] .....................30
3.15. ATOMIC_AGGREGATE / Section 5.1.6 [RFC4271] ...............31
3.16. AGGREGATOR / Section 5.1.7 [RFC4271] .....................32
3.17. BGP Error Handling / Section 6 [RFC4271] .................34
3.18. Message Header Error Handling / Section 6.1 [RFC4271] ....34
3.19. OPEN Message Error Handling / Section 6.2 [RFC4271] ......36
3.20. UPDATE Message Error Handling / Section 6.3 [RFC4271] ....40
3.21. NOTIFICATION Message Error Handling / Section 6.4
[RFC4271] ................................................50
3.22. Hold Timer Expired Error Handling / Section 6.5
[RFC4271] ................................................51
3.23. Finite State Machine Error Handling / Section 6.6
[RFC4271] ................................................51
3.24. Cease / Section 6.7 [RFC4271] ............................51
3.25. BGP Connection Collision Detection / Section 6.8
[RFC4271] ................................................53
3.26. BGP Version Negotiation / Section 7 [RFC4271] ............54
3.27. BGP Finite State Machine (FSM) / Section 8 [RFC4271] .....55
3.28. Administrative Events / Section 8.1.2 [RFC4271] ..........55
3.29. Timer Events / Section 8.1.3 [RFC4271] ...................61
3.30. TCP Connection-Based Events / Section 8.1.4 [RFC4271] ....62
3.31. BGP Messages-Based Events / Section 8.1.5 [RFC4271] ......63
3.32. FSM Definition / Section 8.2.1 [RFC4271] .................65
3.33. FSM and Collision Detection / Section 8.2.1.2 [RFC4271] ..66
3.34. FSM Event numbers / Section 8.2.1.4 [RFC4271] ............66
3.35. Finite State Machine / Section 8.2.2 [RFC4271] ...........67
3.36. UPDATE Message Handling / Section 9 [RFC4271] ............67
3.37. Decision Process / Section 9.1 [RFC4271] .................69
3.38. Phase 1: Calculation of Degree of Preference /
Section 9.1.1 ............................................70
3.39. Phase 2: Route Selection / Section 9.1.2 [RFC4271] .......71
3.40. Route Resolvability Condition / Section 9.1.2.1
[RFC4271] ................................................73
3.41. Breaking Ties (Phase 2) / Section 9.1.2.2 [RFC4271] ......74
3.42. Phase 3: Route Dissemination / Section 9.1.3 [RFC4271] ...76
3.43. Overlapping Routes / Section 9.1.4 [RFC4271] .............77
3.44. Update-Send Process / Section 9.2 [RFC4271] ..............79
3.45. Frequency of Route Advertisement / Section
9.2.1.1 [RFC4271] ........................................81
3.46. Aggregating Routing Information / Section 9.2.2.2
[RFC4271] ................................................82
3.47. Route Selection Criteria / Section 9.3 [RFC4271] .........87
3.48. Originating BGP Routes / Section 9.4 [RFC4271] ...........88
3.49. BGP Timers / Section 10 [RFC4271] ........................88
3.50. TCP Options that May Be Used with BGP / Appendix
E [RFC4271] ..............................................91
3.51. Reducing Route Flapping / Appendix F.2 [RFC4271] .........92
3.52. Complex AS_PATH aggregation / Appendix F.6 [RFC4271] .....92
3.53. Security Considerations [RFC4271] ........................92
4. Additional BGP Implementations Information .....................93
4.1. Avici .....................................................93
4.2. Data Connection Ltd. ......................................94
4.3. Nokia .....................................................94
5. Security Considerations ........................................95
6. Normative References ...........................................95
7. Acknowledgements ...............................................961. Introduction ✨
So this doc reports results from a survey of BGP-4 implementations, where BGP-4 is the version specified in [RFC4271] 🌈 RFC 4271 lines up with how BGP-4 is actually deployed today, and it obsoletes the old BGP standard, [RFC1771] 💅 BGP is a widely deployed cornerstone of Internet technology, and it keeps adding features as the Internet's needs change 🧚
In the real world, BGP-4 is more than just the base spec. It also comes with extra specs like TCP MD5 [RFC2385], BGP Route Reflectors [RFC2796], BGP Confederations [RFC3065], and BGP Route Refresh [RFC2918] 🎀
The BGP-4 implementation survey had 259 detailed questions about compliance with [RFC4271] 📋 Four implementers finished it (Alcatel, Cisco, Laurel, and NextHop), and Section 3 is where all of their results get compiled 💖
Section 2.1 highlights the big differences, Section 2.2 gives an overview of the differences between the four implementations, and Section 2.3 covers interoperability 🦋
Here's the tea 🫖 There are a lot of BGP implementations but only a few people responded, so the editors ran an informal survey to find out whether the survey being so long was why people didn't submit. Three implementers replied, and all three said yes, the length was the problem 😭 Section 4 gives the results of that informal survey.
Overall, the editors compiled both the implementation survey results and the informal survey results into this one document 🍓
1.1. Conventions Used in This Document
Okay, the key words are the important part here 🔑 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 💜
2. Results of Survey 📊
Every respondent replied "Y" (yes) or "N" (no) to the survey's 259 questions, to show whether their implementation supports the Functionality/Description of the [RFC2119] language in [RFC4271] ✨ If the answer was neither yes nor no (for example, an alternate behavior), they replied "O" (other) 🌸
2.1. Significant Differences 🔥
Most questions got affirmative responses from at least two implementers (aka two "Y" responses, or one "Y" and one "O"). The exceptions are below, and these are the drama bits 👀
a) MUST - Linked Questions 212/213, regarding Section 9.1.4
Because of how the linked questions were formatted, three vendors (Cisco, Laurel, and NextHop) replied "N" to Question 213. (See Section 2.2 for details.) 🙈
b) SHALL NOT - Question 228, regarding Section 9.2.2.2
Three vendors (Alcatel, Cisco, and Laurel) answered "N" to SHALL NOT, which means they did do it 💀 One vendor (NextHop) indicated "O" to match the specification 🫶
The spec text says:
Text: Routes that have different MULTI_EXIT_DISC attribute SHALL
NOT be aggregated. (Section 9.2.2.2, [RFC4271])c) SHOULD - Questions 257 and 258, regarding Appendix F
Three vendors answered "N" and one vendor answered "Y" to Question 257. All four vendors answered "N" to Question 258. (Heads up, support of Appendix F, "Implementation Recommendations", is optional 🧚)
The spec text says:
Text: A BGP speaker which needs to withdraw a destination and
send an update about a more specific or less specific route
SHOULD combine them into the same UPDATE message.
(Appendix F.2, [RFC4271])Text: The last instance (rightmost occurrence) of that AS number
is kept. (Appendix F.6, [RFC4271])d) MAY - Questions 180 and 254, regarding Sections 8.1.2.4 and 10
Three vendors answered "N", and one replied "Y" to Question 180 🌈
The spec text says:
Text: The Event numbers (1-28) utilized in this state machine
description aid in specifying the behavior of the BGP state
machine. Implementations MAY use these numbers to provide
network management information. The exact form of a FSM or
the FSM events are specific to each implementation.
(Section 8.1.2.4, [RFC4271])The editors added a little note here too 📝
Editors' note: Section 8.1.2.4 was written to allow existing
implementations to transition to the new event
numbering. It was expected over time (3 years)
that the FSM event numbering would be updated to
the new numbering.Then for Question 254, which is about configurable jitter time values, three vendors answered "N" and one answered "Y" 🎀
The spec text says:
Text: A given BGP speaker MAY apply the same jitter to each of
these quantities regardless of the destinations to which
the updates are being sent; that is, jitter need not be
configured on a "per peer" basis. (Section 10, [RFC4271])And the question they were asking is: Is the jitter range configurable? 🤔
2.2. Overview of Differences 🔍
okay bestie, this is the shortcut 💅 It shows every spot where the four implementations didn't all say "Y." The numbers are question numbers, and each one matches the last digit of a subsection number in Section 3, so question 97 is 3.x.97 ✨
MUST
97, 106, 107, 111, 122, 125, 138, 141, 213
SHALL
233, 239
SHALL NOT
228
SHOULD
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
SHOULD NOT
226
MAY
67, 94, 121, 143, 180, 223, 247, 254
Other
236, 238
Linked Questions
212/213Now the tea 🍵 Questions 212 and 213 are linked, so they get read together. Three vendors said "N" and one said "Y" to Question 213, which is about aggregating routes. Question 212 is the one that says:
"The decision process MUST either install
both routes or..."Question 213 says:
"Aggregate the two routes and install the
aggregated route, provided that both routes have the same value
of the NEXT_HOP attribute"Out of the four people who said "Y" to 212, three said "N" to 213. Given the context of the question, answering "N" to 213 is the right call 🙌
2.3. Implementations and Interoperability 🤝
This table shows which pairs of vendors have interoperated (a "Y" means they did):
Alcatel Cisco Laurel NextHop
Alcatel Y Y
Cisco Y
Laurel Y Y
NextHop Y Y2.4. BGP Implementation Identification 🪪
Here's who's who, with their version info and contacts (the vibes are immaculate 👑):
1.6.0 Alcatel
Implementation Name/Version:
Alcatel 7750 BGP Implementation Release 1.3
Date: July 2003
Contact Name: Devendra Raut
Contact Email: Devendra.raut@Alcatel.com
1.6.1 Cisco
Implementation Name/Version: Cisco BGP Implementation, 12.0(27)S
Contact Name: Alvaro Retana
Date: 11/26/2003
1.6.2 Laurel
Implementation Name/Version: Laurel Networks 3.0
Contact Name: Manish Vora
Contact Email: vora@laurelnetworks.com
Date: 2/1/2004
1.6.3 NextHop Technologies
Implementation Name/Version: Gated NGC 2.0, 2.2
Date: January 20043. BGP-4 Implementation Report 📋
this is the big checklist, and it's where the receipts live 🧾 For every item, each respondent said whether their implementation supports the Functionality/Description, as Y or N, using the [RFC2119] language that applies. Any comments they wrote are included too. If an answer didn't fit neatly into Y/N (an alternate behavior, for example), they used O instead. For more detail, go check the matching sections of [RFC4271]. The last digit of each subsection number is the survey question number 🦋
3.0. Summary of Operation / Section 3 [RFC4271] 🌸
3.0.1. Base Behavior 💖
Functionality/Description: Is your implementation compatible with the base behavior described in this section?
RFC2119: N/A
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.0.2. Local Policy Changes ✨
Functionality/Description: To let local policy changes take effect without resetting any BGP connections, a BGP speaker SHOULD either (a) retain the current version of the routes advertised to it by all of its peers for the duration of the connection, or (b) make use of the Route Refresh extension [RFC2918]
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.1. Routes: Advertisement and Storage / Section 3.1 [RFC4271] 🛣️
3.1.3. Withdraw Routes from Service 🚪
Functionality/Description: Does your implementation support the three methods described in this section?
RFC2119: N/A
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.1.4. Path Attributes 🎀
Functionality/Description: Added to or modified before advertising the route
RFC2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.2. Routing Information Bases / Section 3.2 [RFC4271] 🗂️
3.2.5. Routing Information Bases 🧚
Functionality/Description: Is your implementation compatible with the RIB structure described in this section?
RFC2119: N/A
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.2.6. Next Hop Resolution 🍓
Functionality/Description: The next hop for each route in the Loc-RIB MUST be resolvable via the local BGP speaker's Routing Table
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.3. Message Formats / Section 4 [RFC4271] 📨
3.3.7. Message Size 📏
Functionality/Description: Does your implementation support the message sizes described in this section?
RFC2119: N/A
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.4. Message Header Format / Section 4.1 [RFC4271] 🧱
3.4.8. Marker 🔒
Functionality/Description: MUST be set to all ones
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.4.9. Length 📐
Functionality/Description: MUST always be at least 19 and no greater than 4096
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.4.10. Length 📐
Functionality/Description: MAY be further constrained, depending on the message type
RFC2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.4.11. Message "Padding" 🙈
Functionality/Description: No "padding" of extra data after the message is allowed, so the Length field MUST have the smallest value required given the rest of the message
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.5. OPEN Message / Section 4.2 [RFC4271] 🔓
3.5.12. Hold Timer Calculation ⏱️
Functionality/Description: Use the smaller of its configured Hold Time and the Hold Time received in the OPEN message
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.5.13. Minimum Hold Time ⏳
Functionality/Description: MUST be either zero or at least three seconds
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.5.14. Connection Rejection 🚫
Functionality/Description: Based on the Hold Time
RFC2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y Sends notification.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.6. UPDATE Message Format / Section 4.3 [RFC4271] 🔄
3.6.15. UPDATE 💌
Functionality/Description: Simultaneously advertise a feasible route and withdraw multiple unfeasible routes from service
RFC2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: O We have capability to process this
functionality on receiving end but
we don't send feasible & unfeasible
simultaneously.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.6.16. Transitive Bit Setting 🌈
Functionality/Description: For well-known attributes, the Transitive bit MUST be set to 1
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.6.17. Partial Bit Setting 🧩
Functionality/Description: For well-known attributes and for optional non-transitive attributes the Partial bit MUST be set to 0
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.6.18. Attribute Flags Octet Sending 🚩
Functionality/Description: Lower-order four bits set to zero
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.6.19. Attribute Flags Octet Receiving 📥
Functionality/Description: Lower-order four bits ignored
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.6.20. NEXT_HOP 👑
Functionality/Description: Used as the next hop to the destinations listed in the NLRI field of the UPDATE message
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.6.21. MULTI_EXIT_DISC 🚪
Functionality/Description: Used by a BGP speaker's decision process to discriminate among multiple entry points to a neighboring autonomous system
RFC2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.6.22. AGGREGATOR IP Address 🏷️
Functionality/Description: Same address as the one used for the BGP Identifier of the speaker
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y Default behavior. Can be configured
different from BGP ID.
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.6.23. UPDATE messages that include the same address prefix in the WITHDRAWN ROUTES and Network Layer Reachability Information fields 🫣
Functionality/Description: UPDATE messages SHOULD NOT include that information
RFC2119: SHOULD NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.6.24. UPDATE messages that include the same address prefix in the WITHDRAWN ROUTES and Network Layer Reachability Information fields 🛡️
Functionality/Description: The BGP speaker MUST be able to handle them
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.6.25. UPDATE messages that include the same address prefix in the WITHDRAWN ROUTES and Network Layer Reachability Information fields 🎯
Functionality/Description: Treated as if the WITHDRAWN ROUTES doesn't contain the address prefix
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y Withdrawn routes are processed
before NLRI fields. Hence we get
the desired behavior.
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.7. KEEPALIVE Message Format / Section 4.4 [RFC4271] 💖
Okay bestie, KEEPALIVE time 🦋 These are the tiny "still here!" messages, and this bit is all about how often they can be sent and what happens when the hold time is 0 🧚
3.7.26. Maximum KEEPALIVE Frequency 🌸
Functionality/Description: Not greater than one second
RFC2119: MUST NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.7.27. KEEPALIVE Messages Rate ✨
Functionality/Description: Adjusted as a function of the Hold
Time interval
RFC2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.7.28. Negotiated Hold Time of 0 🙈
Functionality/Description: No KEEPALIVEs sent
RFC2119: MUST NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.8. NOTIFICATION Message Format / Section 4.5 [RFC4271] 🔥
Next up are NOTIFICATION messages, the "something went wrong" ones 💀
3.8.29. NOTIFICATION Message 💅
Functionality/Description: Does your implementation support the
NOTIFICATION Message as described in this section?
RFC2119: N/A
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.9. Path Attributes /Section 5 [RFC4271] 👑
This is the big one, the whole attribute zone 🌈 Lots of little rules in here, so grab a snack 🍓
3.9.30. Path Attributes ✨
Functionality/Description: Does your implementation support the
path attributes as described in this section?
RFC2119: N/A
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.9.31. Well-Known Attributes 🦋
Functionality/Description: Recognized by all BGP implementations
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.9.32. Mandatory Attributes 💖
Functionality/Description: Included in every UPDATE message that
contains NLRI
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.9.33/34. Discretionary Attributes 🌸
Functionality/Description: Sent in a particular UPDATE message
RFC2119: MAY or MAY NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.9.35. Well-Known Attributes 🧚
Functionality/Description: Passed along (after proper updating,
if necessary) to other BGP peers
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.9.36. Optional Attributes 🌈
Functionality/Description: In addition to well-known attributes,
each path MAY contain one or more optional attributes
RFC2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.9.37. Unrecognized Transitive Optional Attributes 🫶
Functionality/Description: Accepted
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.9.38. Partial Bit for Unrecognized Transitive Optional Attributes ⭐
Functionality/Description: Set to 1 if the attribute is accepted
and passed to other BGP speakers
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.9.39. Unrecognized Non-Transitive Optional Attributes 💀
Functionality/Description: Quietly ignored and not passed along
to other BGP peers
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.9.40. New Transitive Optional Attributes 💜
Functionality/Description: Attached to the path by the
originator or by any other BGP speaker in the path
RFC2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.9.41. Optional Attributes 🎀
Functionality/Description: Updated by BGP speakers in the path
RFC2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.9.42. Path Attributes 🔥
Functionality/Description: Ordered in ascending order of
attribute type
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: O All attributes are ordered in
ascending order except Extended
Community, which is type 16 but we
send it out after community
attribute.
Laurel Y/N/O/Comments: Y except for MBGP which is always last
NextHop Y/N/O/Comments: Y3.9.43. Out of Order Received Path Attributes 👑
Functionality/Description: Receiver MUST be able to handle
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.9.44. Mandatory Attributes 🌸
Functionality/Description: Present in all exchanges if NLRI are
contained in the UPDATE message
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.10. ORIGIN / Section 5.1.1 [RFC4271] 🦋
Now ORIGIN, the attribute that tells you where the route started 🍓
3.10.45. ORIGIN ✨
Functionality/Description: Value SHOULD NOT be changed by any
speaker, except the originator
RFC2119: SHOULD NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.11. AS_PATH / Section 5.1.2 [RFC4271] 🌈
And last but not least, AS_PATH, the list of ASs the route has been through. Lots of drama here, bestie 💅
3.11.46. AS_PATH 🔥
Functionality/Description: Not modified when advertising a route
to an internal peer
RFC2119: SHALL NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.11.47. Segment Overflow 💀
Functionality/Description: If the act of prepending will cause
an overflow in the AS_PATH segment, i.e., more than 255 ASs, it
SHOULD prepend a new segment of type AS_SEQUENCE and prepend its
own AS number to this new segment
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.11.48. Prepending 🫶
Functionality/Description: The local system MAY include/prepend
more than one instance of its own AS number in the AS_PATH
attribute
RFC2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.12. NEXT_HOP / Section 5.1.3 [RFC4271] 🌸
3.12.49. NEXT_HOP ✨
okay so NEXT_HOP is basically the next hop to all the destinations listed in the UPDATE message 🦋
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.12.50. NEXT_HOP 💅
when you're sending a message to an internal peer and the route was NOT locally originated, the BGP speaker SHOULD NOT touch the NEXT_HOP attribute 🙈 the only exception is if it was explicitly configured to announce its own IP address as the NEXT_HOP. no cap, hands off unless told otherwise 🫶
RFC2119: SHOULD NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.12.51. NEXT_HOP 🌈
when a speaker announces a route it originated itself to an internal peer, it SHOULD put the interface address of the router that the announced network is reachable through (from the speaker's point of view) into NEXT_HOP. that's giving organized ✨
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.12.52. NEXT_HOP 🧚
so if the route is directly connected to the speaker, OR the interface address of the router the announced network is reachable through is the internal peer's own address, then the speaker SHOULD use its OWN IP address for NEXT_HOP. that's the address of the interface it uses to reach the peer. main character energy, the speaker just points at itself 👑
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.12.53. "First Party" NEXT_HOP 🎀
if the external peer you're advertising to shares a common subnet with one of the speaker's interfaces, the speaker MAY use that interface's IP address in NEXT_HOP. it's optional, but it's a super cute move 💖
RFC2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.12.54. Default NEXT_HOP 🍓
the default is the IP address of the interface the speaker uses to set up the BGP connection to peer X. simple, reliable, and it's giving "I know who I am" 🫶
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.12.55. NEXT_HOP Propagation 🦋
the speaker MAY be configured to propagate NEXT_HOP. when it does, a route it learned from one of its peers gets advertised with the exact same NEXT_HOP it arrived with. the speaker just doesn't touch it 🙌
RFC2119: MAY
Alcatel Y/N/O/Comments: O
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.12.56. Third Party NEXT_HOP 🔥
the speaker MUST be able to support turning this off. the ability to disable it is a must-have, bestie 💅
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.12.57. NEXT_HOP 🌸
a route originated by a BGP speaker SHALL NOT be advertised to a peer using that peer's own address as NEXT_HOP. that would be so awkward 💀
RFC2119: SHALL NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.12.58. NEXT_HOP ⭐
a BGP speaker SHALL NOT install a route with itself as the next hop. no self-referencing routes, we don't do that here 🙈
RFC2119: SHALL NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.12.59. NEXT_HOP 🧚
NEXT_HOP is what figures out the actual outbound interface and the immediate next-hop address that SHOULD be used to forward transit packets to the associated destinations. it's the GPS for packets 🗺️✨
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.12.60. Resolved NEXT_HOP IP Address 💜
if the entry specifies an attached subnet but NOT a next-hop address, then the address in the NEXT_HOP attribute SHOULD be used as the immediate next-hop address. fallback era, but make it make sense 🌈
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.12.61. Resolved NEXT_HOP IP Address 👑
if the entry DOES specify a next-hop address, that address SHOULD be used as the immediate next-hop address for packet forwarding. the entry's own address wins, periodt 💅
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.13. MULTI_EXIT_DISC / Section 5.1.4 [RFC4271] 🦋
3.13.62. Preferred Metric 🌸
the preferred metric is the lowest value. lower is better, so the lowest value SHOULD be the one you pick 🫶
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.13.63. MULTI_EXIT_DISC ✨
if MULTI_EXIT_DISC was received over EBGP, it MAY get propagated over IBGP to other BGP speakers inside the same AS. optional sharing, very generous of it 💖
RFC2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.13.64. MULTI_EXIT_DISC 🙈
if it came from a neighboring AS, it MUST NOT be propagated to other neighboring ASes. keep it private, it's not for the group chat 🤫
RFC2119: MUST NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.13.65. Remove MULTI_EXIT_DISC 🔥
there's a local configuration mechanism to remove the attribute from a route. this one MUST be there, no debate 💅
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.13.66. Remove MULTI_EXIT_DISC 🌈
this removal is done prior to determining the degree of preference of the route and performing route selection. timing is everything, and this MAY happen at that point 🧚
RFC2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.13.67. MULTI_EXIT_DISC Alteration 🎀
an implementation MAY also (based on local configuration) alter the value of the MULTI_EXIT_DISC attribute it received over EBGP. local config gets the final say, iykyk 🤭
RFC2119: MAY
Alcatel Y/N/O/Comments: O
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.13.68. MULTI_EXIT_DISC Alteration 💜
same vibe as the last one: this alteration is done prior to determining the degree of preference of the route and performing route selection, and it MAY happen then 🦋
RFC2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.14. LOCAL_PREF / Section 5.1.5 [RFC4271] 👑
3.14.69. LOCAL_PREF 🌸
LOCAL_PREF is included in all UPDATE messages that a given BGP speaker sends to its other internal peers. it's the tag that goes everywhere inside the family 🫶
RFC2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.14.70. Degree of Preference ✨
the degree of preference gets calculated for each external route based on the locally configured policy. it's then included when advertising the route to internal peers. the policy does the math, and the speaker shares the result 🧮💖
RFC2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.14.71. LOCAL_PREF 🔥
a higher degree of preference MUST be preferred. the bigger number wins, that's just the rule 👑
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.14.72. LOCAL_PREF 🙈
LOCAL_PREF is NOT included in UPDATE messages sent to external peers, except for the case of BGP Confederations [RFC3065]. it stays in the house 🏠
RFC2119: MUST NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.14.73. LOCAL_PREF 🌈
LOCAL_PREF gets ignored if it's received from an external peer, except for the case of BGP Confederations [RFC3065]. the speaker just doesn't listen to that one, no cap 🙅♀️
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.15. ATOMIC_AGGREGATE / Section 5.1.6 [RFC4271] 🧚
3.15.74. ATOMIC_AGGREGATE 💅
ATOMIC_AGGREGATE is included if an aggregate excludes at least some of the AS numbers present in the AS_PATH of the routes that got aggregated, as a result of dropping the AS_SET. it's the "some info got left out" badge 🎀
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.15.75. Received ATOMIC_AGGREGATE 🫶
when a BGP speaker receives ATOMIC_AGGREGATE, it SHOULD NOT remove the attribute from the route when propagating it to other speakers. keep the badge on, it's giving honesty 🦋
RFC2119: SHOULD NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.15.76. Received ATOMIC_AGGREGATE 🔥
a BGP speaker MUST NOT make any NLRI of that route more specific (as defined in 9.1.4). no splitting it up into smaller pieces, bestie, that's a hard no 🙅♀️💀
RFC2119: MUST NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.16. AGGREGATOR / Section 5.1.7 [RFC4271] 🌸
3.16.77. AGGREGATOR ✨
AGGREGATOR is included in updates that are formed by aggregation (see Section 9.2.2.2). totally optional, but very on-brand for aggregated routes 🌈
RFC2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.16.78. AGGREGATOR 💖
it gets added by the BGP speaker that's doing the route aggregation. the aggregator gets its name on the list 📝✨
RFC2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.16.79. AGGREGATOR 👑
AGGREGATOR SHALL contain the local AS number and IP address. it's the speaker's ID card, so it has to be there 🪪
RFC2119: SHALL
Alcatel Y/N/O/Comments: Y Default behavior. Can be configured
different from BGP ID.
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.16.80. AGGREGATOR IP Address 🧚
the AGGREGATOR IP address is the same as the BGP Identifier of the speaker. SHOULD be a match, so it's all consistent and iconic 🦋
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.17. BGP Error Handling / Section 6 [RFC4271] ✨
okay the error handling section is where things get real 😭 we're checking whether each implementation handles the error paths the way the spec describes 🫶
3.17.81. Error Handling
Functionality/Description: Is your implementation compatible
with the error handling procedures described in this section?
RFC2119: N/A
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.17.82. Error Subcode
Functionality/Description: Zero, if it is not specified
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.18. Message Header Error Handling / Section 6.1 [RFC4271] 🎀
the message header era, where everything has to be just right 💅
3.18.83. Message Header Errors
Functionality/Description: Indicated by sending the NOTIFICATION
message with Error Code Message Header Error
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.18.84. Synchronization Error
Functionality/Description: Error Subcode MUST be set to
Connection Not Synchronized
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.18.85. Message Length
Functionality/Description: Use the Bad Message Length Error
Subcode to indicate an incorrect message length
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.18.86. Bad Message Length
Functionality/Description: The Data field MUST contain the
erroneous Length field
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.18.87. Type Field
Functionality/Description: If the Type field of the message
header is not recognized, then the Error Subcode MUST be set to
Bad Message Type
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.18.88. Bad Message Type
Functionality/Description: The Data field MUST contain the
erroneous Type field
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.19. OPEN Message Error Handling / Section 6.2 [RFC4271] 🦋
the OPEN message errors, and this is where the Hold Time drama lives 🙈
3.19.89. OPEN Message Errors
Functionality/Description: Indicated by sending the NOTIFICATION
message with Error Code OPEN Message Error
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.19.90. Version Number Not Supported
Functionality/Description: The Error Subcode MUST be set to
Unsupported Version Number
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.19.91. Unacceptable Autonomous System Field
Functionality/Description: The Error Subcode MUST be set to Bad
Peer AS
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.19.92. Unacceptable Hold Time Error Subcode
Functionality/Description: Used if the Hold Time field of the
OPEN message is unacceptable
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.19.93. Hold Time Rejection
Functionality/Description: Values of one or two seconds
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.19.94. Hold Time Rejection
Functionality/Description: An implementation may reject any
proposed Hold Time
RFC2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: N
NextHop Y/N/O/Comments: Y3.19.95. Hold Time
Functionality/Description: If accepted, then the negotiated
value MUST be used
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.19.96. Syntactically Incorrect BGP Identifier
Functionality/Description: The Error Subcode MUST be set to Bad
BGP Identifier
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.19.97. Not Recognized Optional Parameters
Functionality/Description: The Error Subcode MUST be set to
Unsupported Optional Parameters
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: N We may fix this.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.19.98. Recognized but Malformed Optional Parameters
Functionality/Description: The Error Subcode MUST be set to 0
(Unspecific)
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: N
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.20. UPDATE Message Error Handling / Section 6.3 [RFC4271] 👑
the UPDATE message errors, the longest stretch of this whole section, so grab a snack 🍓✨
3.20.99. UPDATE Message Errors
Functionality/Description: Indicated by sending the
NOTIFICATION message with Error Code UPDATE Message Error
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.20.100. Too Large
Functionality/Description: If the Withdrawn Routes Length or
Total Attribute Length is too large, then the Error Subcode MUST
be set to Malformed Attribute List
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.20.101. Conflicting Flags
Functionality/Description: If any recognized attribute has
Attribute Flags that conflict with the Attribute Type Code, then
the Error Subcode MUST be set to Attribute Flags Error
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.20.102. Conflicting Flags
Functionality/Description: The Data field MUST contain the
erroneous attribute
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.20.103. Conflicting Length
Functionality/Description: If any recognized attribute has
Attribute Length that conflicts with the expected length, then
the Error Subcode MUST be set to Attribute Length Error
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.20.104. Conflicting Length
Functionality/Description: The Data field MUST contain the
erroneous attribute
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.20.105. Missing Mandatory Well-Known Attributes
Functionality/Description: The Error Subcode MUST be set to
Missing Well-known Attribute
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.20.106. Missing Mandatory Well-Known Attributes
Functionality/Description: The Data field MUST contain the
Attribute Type Code of the missing well-known attribute
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: N We plan to fix this in future.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.20.107. Unrecognized Mandatory Well-Known Attributes
Functionality/Description: The Error Subcode MUST be set to
Unrecognized Well-known Attribute
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: N We set error subcode to Attribute
Flags Error, but we intend to
correct this soon.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.20.108. Unrecognized Mandatory Well-Known Attributes
Functionality/Description: The Data field MUST contain the
unrecognized attribute
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.20.109. Undefined ORIGIN
Functionality/Description: The Error Sub-code MUST be set to
Invalid Origin Attribute
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.20.110. Undefined ORIGIN
Functionality/Description: The Data field MUST contain the
unrecognized attribute
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.20.111. Syntactically Incorrect NEXT_HOP
Functionality/Description: The Error Subcode MUST be set to
Invalid NEXT_HOP Attribute
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: N Ignores the prefix in case of
martian nexthop, and in case of
length not equal to IPv4
address-length, we send
NOTIFICATION with error subcode
Attribute Length error.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.20.112. Syntactically Incorrect NEXT_HOP
Functionality/Description: The Data field MUST contain the
incorrect attribute
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.20.113. NEXT_HOP Semantic Correctness
Functionality/Description: NEXT_HOP is checked for semantic
correctness against the criteria in this section
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.20.114. NEXT_HOP Semantic Correctness
Functionality/Description: Not be the IP address of the
receiving speaker
RFC2119: MUST NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.20.115. NEXT_HOP Semantic Correctness
Functionality/Description: In the case of an EBGP where the
sender and receiver are one IP hop away from each other, either
the IP address in the NEXT_HOP MUST be the sender's IP address
(that is used to establish the BGP connection), or the interface
associated with the NEXT_HOP IP address MUST share a common
subnet with the receiving BGP speaker
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.20.116. Semantically Incorrect NEXT_HOP
Functionality/Description: Error logged
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: YAlcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.20.117. Semantically Incorrect NEXT_HOP
Functionality/Description: Route Ignored 🙈
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: N
NextHop Y/N/O/Comments: Y3.20.118. Semantically Incorrect NEXT_HOP
Functionality/Description: NOTIFICATION not sent 💀
RFC2119: SHOULD NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.20.119. Semantically Incorrect NEXT_HOP
Functionality/Description: Connection not closed 🫶
RFC2119: SHOULD NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.20.120. Syntactically Incorrect AS_PATH
Functionality/Description: The Error Subcode MUST be set to Malformed AS_PATH 💅
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.20.121. First Neighbor in AS_PATH Check
Functionality/Description: Okay so if the UPDATE message comes from an external peer, the local system MAY check whether the leftmost AS in the AS_PATH attribute matches the autonomous system number of the peer that sent the message 🦋
RFC2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: N
NextHop Y/N/O/Comments: Y3.20.122. First Neighbor in AS_PATH Check
Functionality/Description: If that check finds that the leftmost AS does not match, the Error Subcode MUST be set to Malformed AS_PATH 😭
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: n/a
NextHop Y/N/O/Comments: Y3.20.123. Optional Attributes
Functionality/Description: The Value MUST be checked if the attribute is recognized 🔥
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.20.124. Optional Attribute Error
Functionality/Description: The attribute MUST be discarded 🗑️
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.20.125. Optional Attribute Error
Functionality/Description: The Error Subcode MUST be set to Optional Attribute Error 🎀
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: N What exactly is optional attribute
e.g., If error is flag related, we
send update flag error subcode, if it
is length related, we send update
length error subcode. These granular
subcodes are better in terms of
debugging than optional attribute
error.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y Only optional attribute error that
doesn't have a more specific error,
is the version 3 to version 4 error
for the atomic aggregate. All others
default to more specific error codes
if implementation.3.20.126. Optional Attribute Error
Functionality/Description: The Data field MUST contain the attribute 🧚
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.20.127. Duplicate Attributes
Functionality/Description: If any attribute shows up more than once in the UPDATE message, then the Error Subcode MUST be set to Malformed Attribute List 👑
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.20.128. Syntactically Incorrect NLRI Field
Functionality/Description: The Error Subcode MUST be set to Invalid Network Field 🌸
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.20.129. Semantically Incorrect NLRI Field
Functionality/Description: An error SHOULD be logged locally 📝
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.20.130. Semantically Incorrect NLRI Field
Functionality/Description: The prefix SHOULD be ignored 🙈
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.20.131. UPDATE with no NLRI
Functionality/Description: An UPDATE message that has correct path attributes but no NLRI SHALL be treated as a valid UPDATE message ✨
RFC2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.21. NOTIFICATION Message Error Handling / Section 6.4 [RFC4271] 🌈
3.21.132. Error in NOTIFICATION Message
Functionality/Description: Noticed, logged locally, and brought to the attention of the administration of the peer 👀
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: N
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.22. Hold Timer Expired Error Handling / Section 6.5 [RFC4271] ⏰
3.22.133. Hold Timer Expired
Functionality/Description: Is your implementation compatible with the error handling procedures described in this section? 🤔
RFC2119: N/A
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.23. Finite State Machine Error Handling / Section 6.6 [RFC4271] 🦋
3.23.134. Finite State Machine Errors
Functionality/Description: Is your implementation compatible with the error handling procedures described in this section? 🤔
RFC2119: N/A
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: N
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.24. Cease / Section 6.7 [RFC4271] 💅
3.24.135. Cease NOTIFICATION
Functionality/Description: Used in the absence of any fatal errors if a BGP peer chooses, at any given time, to close its BGP connection 👋
RFC2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: N We close the TCP session without
CEASE NOTIFICATION.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.24.136. Cease NOTIFICATION
Functionality/Description: Not used for specified fatal errors 🚫
RFC2119: MUST NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.24.137. Upper bound on the number of address prefixes the speaker is willing to accept from a neighbor
Functionality/Description: Support by local configuration ⚙️
RFC2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.24.138. Upper bound on the number of address prefixes the speaker is willing to accept from a neighbor
Functionality/Description: If that limit is exceeded and the BGP speaker decides to terminate its BGP connection, the Cease NOTIFICATION MUST be used 😱
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: N We don't send CEASE but we plan to
correct that soon.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y No termination of peers is supported
We are considering support with the
maximum prefix document for later
releases.3.24.139. Upper bound on the number of address prefixes the speaker is willing to accept from a neighbor
Functionality/Description: Log locally 📝
RFC2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.25. BGP Connection Collision Detection / Section 6.8 [RFC4271] 💥
3.25.140. Connection Collision
Functionality/Description: One of the connections MUST be closed 🔒
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.25.141. Receipt of an OPEN Message
Functionality/Description: The local system MUST examine all of its connections that are in the OpenConfirm state 🔍
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: O We detect collision through some
other implementation specific way
and resolve by method specified in
the document.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.25.142. Receipt of an OPEN Message
Functionality/Description: Examine connections in an OpenSent state if it knows the BGP Identifier of the peer by means outside of the protocol 🧐
RFC2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.26. BGP Version Negotiation / Section 7 [RFC4271] 🎀
3.26.143. Version Negotiation
Functionality/Description: Multiple tries to open a BGP connection, starting with the highest version number each side supports 🔁
RFC2119: MAY
Alcatel Y/N/O/Comments: N Supports only version 4
Cisco Y/N/O/Comments: O We resolve it through config. If
Config is for version 3, and we get
version 4, OPEN will always fail.
Similarly, if configed (default) is
version 4 and peers configured is 3,
we don't try to negotiate version 3
unless we have configured it.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: N Supports only version 4.3.26.144. Future Versions of BGP
Functionality/Description: MUST retain the format of the OPEN and NOTIFICATION messages 🌷
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.27. BGP Finite State Machine (FSM) / Section 8 [RFC4271] 🌈
3.27.145. FSM
Functionality/Description: Is your implementation compatible with the conceptual FSM described in this section? 🤔
RFC2119: N/A
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.28. Administrative Events ✨ / Section 8.1.2 [RFC4271]
3.28.146. Optional Session Attribute Settings
Functionality/Description: okay so every event tells you which optional session attributes SHOULD be set at each stage 💅
RFC2119: SHOULD
the vendor receipts 🧾
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: O Its rather vague. We have an option
Of manually starting or stopping
sessions but not an option for all
optional session attributes that are
listed in the document.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y The following optional attributes
are implied in this implementation:
1) Automatic start, 2) Automatic
Stop, 3)3.28.147. Event1: ManualStart
Functionality/Description: the PassiveTcpEstablishment attribute SHOULD be set to FALSE 🌸
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.28.148. Event3: AutomaticStart
Functionality/Description: the AllowAutomaticStart attribute SHOULD be set to TRUE 🦋
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.28.149. Event3: AutomaticStart
Functionality/Description: the PassiveTcpEstablishment optional session attribute SHOULD be set to FALSE 🍓
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.28.150. Event3: AutomaticStart
Functionality/Description: DampPeerOscillations SHOULD be set to FALSE 🙈
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y Don't support DampPeerOscillations
attribute, so it is always FALSE.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.28.151. Event4: ManualStart_with_PassiveTcpEstablishment
Functionality/Description: the PassiveTcpEstablishment attribute SHOULD be set to TRUE 🧚
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y We wait for some fixed time before
initiating OPEN.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.28.152. Event4: ManualStart_with_PassiveTcpEstablishment
Functionality/Description: the DampPeerOscillations attribute SHOULD be set to FALSE ✨
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y Don't support DampPeerOscillations
attribute so it is FALSE.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: O We don't support DampPeerOscilation
attribute with a setting of off, and
hence Event 4. Future version will
support Event 43.28.153. Event5: AutomaticStart_with_PassiveTcpEstablishment
Functionality/Description: the AllowAutomaticStart attribute SHOULD be set to TRUE 👑
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.28.154. Event5: AutomaticStart_with_PassiveTcpEstablishment
Functionality/Description: the PassiveTcpEstablishment attribute SHOULD be set to TRUE 🎀
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.28.155. Event5: AutomaticStart_with_PassiveTcpEstablishment
Functionality/Description: DampPeerOscillations SHOULD be set to FALSE 💅
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y Don't support DampPeerOscillations
attribute, so always FALSE.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: O We don't support DampPeerOscilation
attribute with a setting of off, and
hence Event 5. Future version will
support Event 53.28.156. Event6: AutomaticStart_with_DampPeerOscillations
Functionality/Description: the AllowAutomaticStart attribute SHOULD be set to TRUE 🌈
RFC2119: SHOULD
Alcatel Y/N/O/Comments: N
Cisco Y/N/O/Comments: O Don't support DampPeerOscillations
attribute.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.28.157. Event6: AutomaticStart_with_DampPeerOscillations
Functionality/Description: the DampPeerOscillations attribute SHOULD be set to TRUE 🔥
RFC2119: SHOULD
Alcatel Y/N/O/Comments: N
Cisco Y/N/O/Comments: N Don't support DampPeerOscillations
attribute.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.28.158. Event6: AutomaticStart_with_DampPeerOscillations
Functionality/Description: the PassiveTcpEstablishment attribute SHOULD be set to FALSE 🫶
RFC2119: SHOULD
Alcatel Y/N/O/Comments: N
Cisco Y/N/O/Comments: O Don't support DampPeerOscillations
attribute and hence Event6.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.28.159. Event7: AutomaticStart_with_DampPeerOscillations_and_PassiveTcpEstablishment
Functionality/Description: the AllowAutomaticStart attribute SHOULD be set to TRUE 🦋
RFC2119: SHOULD
Alcatel Y/N/O/Comments: N
Cisco Y/N/O/Comments: O Don't support DampPeerOscillations
attribute and hence Event7
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.28.160. Event7: AutomaticStart_with_DampPeerOscillations_and_PassiveTcpEstablishment
Functionality/Description: the DampPeerOscillations attribute SHOULD be set to TRUE 🌸
RFC2119: SHOULD
Alcatel Y/N/O/Comments: N
Cisco Y/N/O/Comments: O Don't support DampPeerOscillations
attribute and hence Event7
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.28.161. Event7: AutomaticStart_with_DampPeerOscillations_and_PassiveTcpEstablishment
Functionality/Description: the PassiveTcpEstablishment attribute SHOULD be set to TRUE 💜
RFC2119: SHOULD
Alcatel Y/N/O/Comments: N
Cisco Y/N/O/Comments: O Don't support DampPeerOscillations
attribute and hence Event7
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.28.162. Event8: AutomaticStop
Functionality/Description: the AllowAutomaticStop attribute SHOULD be TRUE 🛑✨
RFC2119: SHOULD
Alcatel Y/N/O/Comments: N
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.29. Timer Events ⏰ / Section 8.1.3 [RFC4271]
3.29.163. Event12: DelayOpenTimer_Expires
Functionality/Description: the DelayOpen attribute SHOULD be set to TRUE 🌷
RFC2119: SHOULD
Alcatel Y/N/O/Comments: N
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: n/a
NextHop Y/N/O/Comments: Y3.29.164. Event12: DelayOpenTimer_Expires
Functionality/Description: the DelayOpenTime attribute SHOULD be supported 🧁
RFC2119: SHOULD
Alcatel Y/N/O/Comments: N
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: n/a
NextHop Y/N/O/Comments: Y3.29.165. Event12: DelayOpenTimer_Expires
Functionality/Description: the DelayOpenTimer SHOULD be supported 🎀
RFC2119: SHOULD
Alcatel Y/N/O/Comments: N
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: n/a
NextHop Y/N/O/Comments: Y3.29.166. Event13: IdleHoldTimer_Expires
Functionality/Description: the DampPeerOscillations attribute SHOULD be set to TRUE 💀
RFC2119: SHOULD
Alcatel Y/N/O/Comments: N
Cisco Y/N/O/Comments: O Don't support DampPeerOscillations
attribute and hence Event13
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.29.167. Event13: IdleHoldTimer_Expires
Functionality/Description: the IdleHoldTimer SHOULD have just expired 🙌
RFC2119: SHOULD
Alcatel Y/N/O/Comments: N
Cisco Y/N/O/Comments: O Don't support DampPeerOscillations
attribute and hence Event13
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.30. TCP Connection-Based Events / Section 8.1.4 [RFC4271]
3.30.168. Event14: TcpConnection_Valid
Functionality/Description: BGP's destination port SHOULD be port 179 🍓
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.30.169. Event14: TcpConnection_Valid
Functionality/Description: the TrackTcpState attribute SHOULD be set to TRUE 🔍
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: O GateD NGC 2.0 provides hooks for
the TCP state tracking, but use of
this option depends OS support.
Future versions will have additional
hooks.3.30.170. Event15: Tcp_CR_Invalid
Functionality/Description: BGP destination port number SHOULD be 179 🌈
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: O GateD NGC 2.0 provides hooks for
the TCP state tracking, but use of
this option depends OS support.
Future versions will have additional
hooks.3.31. BGP Messages-Based Events / Section 8.1.5 [RFC4271] 💌
3.31.171. Event19: BGPOpen 🎀
Okay bestie, the description says: The DelayOpen optional attribute SHOULD be set to FALSE ✨
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: n/a
NextHop Y/N/O/Comments: Y3.31.172. Event19: BGPOpen 🦋
This one is giving "don't touch the timer": The DelayOpenTimer SHOULD not be running 🙈
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.31.173. Event20: BGPOpen with DelayOpenTimer Running 🌸
Main character energy: The DelayOpen attribute SHOULD be set to TRUE 👑
RFC2119: SHOULD
Alcatel Y/N/O/Comments: N Not applicable
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: n/a
NextHop Y/N/O/Comments: Y3.31.174. Event20: BGPOpen with DelayOpenTimer Running 🧚
Same vibe, different timer: The DelayOpenTimer SHOULD be running ⏰
RFC2119: SHOULD
Alcatel Y/N/O/Comments: N
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: n/a
NextHop Y/N/O/Comments: Y3.31.175. Event23: OpenCollisionDump 💅
If the state machine is to process this event in Established state, the CollisionDetectEstablishedState optional attribute SHOULD be set to TRUE 🔥
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y Collision detection event is logged.
Cisco Y/N/O/Comments: O We always detect collision before we
go to established state.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: O GateD NGC 2.0 does not support
Collision Detection in Established
state. This option attribute is
always set to FALSE.3.32. FSM Definition / Section 8.2.1 [RFC4271] 🍓
3.32.176. FSM 💖
Separate FSM for each configured peer. This one is a MUST, so no skipping it 🫶
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.32.177. TCP Port 179 🔌
A BGP implementation MUST connect to and listen on TCP port 179 for incoming connections in addition to trying to connect to peers 💜
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.32.178. Incoming Connections 📥
A state machine MUST be instantiated. Non-negotiable, bestie 😭
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.33. FSM and Collision Detection / Section 8.2.1.2 [RFC4271] 🌈
3.33.179. Connection Collision 💫
The corresponding FSM for the connection that is closed SHOULD be disposed of 🗑️
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.34. FSM Event numbers / Section 8.2.1.4 [RFC4271] 🔢
3.34.180. Event Numbers 🙃
Used to provide network management information. This one's a MAY, so it's optional and totally a vibe choice 🌷
RFC2119: MAY
Alcatel Y/N/O/Comments: Y Not visible to operator.
Cisco Y/N/O/Comments: N
Laurel Y/N/O/Comments: N
NextHop Y/N/O/Comments: N Future Release of GateD NGC may
support event numbers.3.35. Finite State Machine / Section 8.2.2 [RFC4271] 🎈
3.35.181. ConnectRetryTimer ⏳
Sufficiently large to allow TCP initialization. It's a SHOULD, so make it roomy 🛏️
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.35.182. Second Connection Tracking 👀
In response to a TCP connection succeeds [Event 16 or Event 17], the 2nd connection SHALL be tracked until it sends an OPEN message. Tracking is a must, no cap 🫡
RFC2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.36. UPDATE Message Handling / Section 9 [RFC4271] 📨
3.36.183. UPDATE Message Handling 🧁
Does your implementation handle UPDATE messages in a manner compatible to the description in this section? It's a N/A on the RFC2119 front, but the vendors checked in anyway 💅
RFC2119: N/A
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.36.184. WITHDRAWN ROUTES 🗑️
Any previously advertised routes whose destinations are contained in this field SHALL be removed from the Adj-RIB-In 🌪️
RFC2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.36.185. WITHDRAWN ROUTES 🔄
The BGP speaker SHALL run its Decision Process since the previously advertised route is no longer available for use. Rerun the process, periodt ✨
RFC2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.36.186. Implicit Withdraw 🫧
If an UPDATE message contains a feasible route, and the NLRI of the new route is identical to the one of a route currently stored in the Adj-RIB-In, then the new route SHALL replace the older route. Glow-up energy 🌟
RFC2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.36.187. Other Feasible Routes 🌿
If an UPDATE message contains a feasible route, and the NLRI of the new route is not identical to the one of any route currently stored in the Adj-RIB-In, then the new route SHALL be placed in the Adj-RIB-In. New route, new spot 🍑
RFC2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.36.188. Adj-RIB-In Update 🔁
Once a BGP speaker updates the Adj-RIB-In, it SHALL run its Decision Process 🧠
RFC2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.37. Decision Process / Section 9.1 [RFC4271] 🏆
3.37.189. Decision Process 🎯
Is your implementation compatible with the description in this section? N/A on the keyword side, but still a big question 💭
RFC2119: N/A
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.37.190. Degree of Preference 🙅♀️
The speaker SHALL NOT use as its inputs any of the following: the existence of other routes, the non-existence of other routes, or the path attributes of other routes. No peeking at the other routes, bestie 🙈
RFC2119: SHALL NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.38. Phase 1: Calculation of Degree of Preference / Section 9.1.1 [RFC4271] 🧮
3.38.191. Ineligible Degree of Preference 🚫
The route MAY NOT serve as an input to the next phase of route selection. It's benched for this round 🪑
RFC2119: MAY NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.38.192. Eligible Degree of Preference 🏅
Used as the LOCAL_PREF value in any IBGP re-advertisement. This one is a MUST, iconic 👑
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.39. Phase 2: Route Selection / Section 9.1.2 [RFC4271] 🗺️
3.39.193. Unresolvable NEXT_HOP 🚧
If the NEXT_HOP attribute of a BGP route depicts an address that is not resolvable, or it would become unresolvable if the route was installed in the routing table the BGP route MUST be excluded. Not resolvable? Out, no debate 🚪
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.39.194. Routes Installed in LOC-RIB 📚
The route in the Adj-RIBs-In identified as the best (see section 9.1.2) is installed in the Loc-RIB, replacing any route to the same destination that is currently being held in the Loc-RIB. Only the best one gets the spotlight 🌟
RFC2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.39.195. Immediate Next-Hop Address 📍
MUST be determined from the NEXT_HOP attribute of the selected route (see Section 5.1.3). No guessing, it's a MUST 🎯
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.39.196. Phase 2: Route Selection 🔁
Performed again if either the immediate next hop or the IGP cost to the NEXT_HOP changes. Things change, so the selection runs again 🔄
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.39.197. Immediate Next-Hop Address 📦
Used for packet forwarding. The MUST here is giving delivery driver 🚚
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.39.198. Unresolvable Routes 🧹
Removed from the Loc-RIB and the routing table. Clean sweep, SHALL do ✨
RFC2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.39.199. Unresolvable Routes 🗂️
Kept in the corresponding Adj-RIBs-In. It's a SHOULD, so keep the receipts 🧾
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.40. Route Resolvability Condition / Section 9.1.2.1 [RFC4271] 🔍
3.40.200. Unresolvable Routes 🙅
Excluded from the Phase 2 decision. Unresolvable routes don't get a seat at this table, SHOULD-wise 🪑
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.40.201. Multiple Matching Routes 🎀
Only the longest matching route SHOULD be considered. Longest match wins, iykyk 💖
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.40.202. Mutual Recursion 🌀
If a route fails the resolvability check because of mutual recursion, an error message SHOULD be logged. Log it, bestie 📝
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: O We have checks that disallow mutual
recursion, so this won't happen.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.41. Breaking Ties (Phase 2) / Section 9.1.2.2 [RFC4271] 💅
okay bestie, this is where the tie-breaking happens and it's giving "who wins" energy 👑 let's go through the criteria one by one ✨
3.41.203. Tie-Breaking Criteria 🎀
Functionality/Description: Applied in the order specified
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.41.204. Algorithm Used 🦋
ngl this one is so chill. any algorithm is fine as long as it gives the same results 🫶
Functionality/Description: BGP implementations MAY use any
algorithm which produces the same results as those described
here
RFC2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.41.205. MULTI_EXIT_DISC Removal 🌸
Functionality/Description: If done before re-advertising a route
into IBGP, then comparison based on the received EBGP
MULTI_EXIT_DISC attribute MAY still be performed
RFC2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.41.206. MULTI_EXIT_DISC Removal 💜
the optional MULTI_EXIT_DISC comparison, if it happens at all, is only among EBGP learned routes. the vibes are very specific here 🙈
Functionality/Description: The optional comparison on
MULTI_EXIT_DISC if performed at all MUST be performed only among
EBGP learned routes
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.41.207. MULTI_EXIT_DISC Comparison 🔥
Functionality/Description: Performed for IBGP learned routes
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.42. Phase 3: Route Dissemination / Section 9.1.3 [RFC4271] 🧚
phase 3 is all about where routes go next, and it's a whole vibe 🌈
3.42.208. Policy for processing routes from the Loc-RIB into Adj-RIBs-Out ✨
this one lets you keep a route out of a particular Adj-RIB-Out, which is so main character of you 💅
Functionality/Description: Exclude a route in the Loc-RIB from
being installed in a particular Adj-RIB-Out
RFC2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.42.209. Adj-Rib-Out Route Installation 🙅♀️
Functionality/Description: Not unless the destination and
NEXT_HOP described by this route may be forwarded appropriately
by the Routing Table
RFC2119: SHALL NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.42.210. Withdraw Routes 🦋
if a route gets excluded from a particular Adj-RIB-Out, the route that was advertised there before has to be pulled back with an UPDATE message (see 9.2). no drama, just a clean exit 👋
Functionality/Description: If a route in Loc-RIB is excluded
from a particular Adj-RIB-Out the previously advertised route in
that Adj-RIB-Out MUST be withdrawn from service by means of an
UPDATE message (see 9.2)
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.43. Overlapping Routes / Section 9.1.4 [RFC4271] 🌸
okay this section is literally the overlapping routes drama and we're here for all of it 🍿
3.43.211. Overlapping Routes 💖
Functionality/Description: Consider both routes based on the
configured acceptance policy
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.43.212. Accepted Overlapping Routes 🎀
Functionality/Description: The Decision Process MUST either
install both routes or...
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.43.213. Accepted Overlapping Routes 🙈
here's where the implementations split. Alcatel is the only one that does the aggregating thing, and Cisco, Laurel and NextHop all have their own takes 👀
Functionality/Description: Aggregate the two routes and install
the aggregated route, provided that both routes have the same
value of the NEXT_HOP attribute
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: N We install both in Local RIB.
Laurel Y/N/O/Comments: N no automatic aggregation
NextHop Y/N/O/Comments: N no automatic aggregation3.43.214. Aggregation 🧁
Functionality/Description: Either include all ASs used to form
the aggregate in an AS_SET or add the ATOMIC_AGGREGATE
attribute to the route
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.43.215. De-Aggregation 💅
Functionality/Description: Routes SHOULD NOT be de-aggregated
RFC2119: SHOULD NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.43.216. Route with the ATOMIC_AGGREGATE Attribute 🔒
Functionality/Description: Not de-aggregated
RFC2119: MUST NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.44. Update-Send Process / Section 9.2 [RFC4271] 📨
this is the part where updates get sent out, and honestly it's giving very organised group chat 🫶
3.44.217. UPDATE Message Received from an Internal Peer 🌈
Functionality/Description: Not re-distribute the routing
information to other internal peers, unless the speaker acts as
a BGP Route Reflector [RFC2796]
RFC2119: SHALL NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.44.218. No Replacement Route ✨
Functionality/Description: All newly installed routes and all
newly unfeasible routes for which there is no replacement route
SHALL be advertised to its peers by means of an UPDATE message
RFC2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.44.219. Previously Advertised Routes 🙅♀️
Functionality/Description: A BGP speaker SHOULD NOT advertise a
given feasible BGP route if it would produce an UPDATE message
containing the same BGP route as was previously advertised
RFC2119: SHOULD NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.44.220. Unfeasible Routes 🗑️
Functionality/Description: Removed from the Loc-RIB
RFC2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.44.221. Changes to Reachable Destinations 🍓
Functionality/Description: Changes to the reachable destinations
within its own autonomous system SHALL also be advertised in an
UPDATE message
RFC2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.44.222. A single route doesn't fit into the UPDATE message 😭
Functionality/Description: Don't advertise
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.44.223. A single route doesn't fit into the UPDATE message 🌸
this is the same heading as the one above, but the reaction is different. Cisco is the one that doesn't do the local error logging 🙈
Functionality/Description: Log an error local
RFC2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: N
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.45. Frequency of Route Advertisement / Section 9.2.1.1 [RFC4271] ⏰
this section is all about timing and how often routes get advertised, so grab a snack because the timers are everything ⏰🍿
3.45.224. MinRouteAdvertisementIntervalTimer 💜
Functionality/Description: Minimum separation between two UPDATE
messages sent by a BGP speaker to a peer that advertise feasible
routes and/or withdrawal of unfeasible routes to some common set
of destinations
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.45.225. Fast Convergence 🚀
this one has the most vendor drama, with Alcatel going configurable per peer, Laurel saying nope, and NextHop giving a config option 👀
Functionality/Description: MinRouteAdvertisementIntervalTimer
used for internal peers SHOULD be shorter than the
MinRouteAdvertisementIntervalTimer used for external peers, or
RFC2119: SHOULD
Alcatel Y/N/O/Comments: O Configurable on per peer basis.
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: N they are same for ebgp and ibgp
NextHop Y/N/O/Comments: Y Configuration option allows to set
the time per peer.3.45.226. Fast Convergence 🧚
Functionality/Description: The procedure describes in this
section SHOULD NOT apply for routes sent to internal peers
RFC2119: SHOULD NOT
Alcatel Y/N/O/Comments: O Operator has to ensure that through
configuration.
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: N
NextHop Y/N/O/Comments: Y Default setting is off for BGP
peers.3.45.227. MinRouteAdvertisementIntervalTimer 💖
Functionality/Description: The last route selected SHALL be
advertised at the end of MinRouteAdvertisementIntervalTimer
RFC2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.46. Aggregating Routing Information / Section 9.2.2.2 [RFC4271] ✨
3.46.228. MULTI_EXIT_DISC 🌸
okay so routes with different MULTI_EXIT_DISC values SHALL NOT be aggregated, no exceptions, bestie 🙅♀️
RFC2119: SHALL NOT
Alcatel Y/N/O/Comments: N
Cisco Y/N/O/Comments: N
Laurel Y/N/O/Comments: N
NextHop Y/N/O/Comments: Y3.46.229. AS_SET as the First Element 💅
if the aggregated route has an AS_SET as the first element in its AS_PATH, then the router that originates the route SHOULD NOT advertise the MULTI_EXIT_DISC attribute with it. lowkey a vibe check moment 🫶
RFC2119: SHOULD NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.46.230. NEXT_HOP 🦋
when you aggregate routes with different NEXT_HOP attributes, the aggregated route's NEXT_HOP SHALL identify an interface on the BGP speaker doing the aggregating. it's giving "own your space" energy ✨
RFC2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.46.231. ORIGIN INCOMPLETE 🔥
used if at least one of the aggregated routes has ORIGIN set to INCOMPLETE. this one is a MUST, no debate 👑
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.46.232. ORIGIN EGP 🌈
same energy as the last one, but for EGP. used if at least one of the aggregated routes has ORIGIN set to EGP, and it is a MUST 💜
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.46.233. Routes to be aggregated have different AS_PATH attributes 🧚
the aggregated AS_PATH attribute SHALL satisfy all of the following conditions: ... (yes, the original literally trails off there, and yes, I'm keeping it 😭)
RFC2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: N
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.46.234. Routes to be aggregated have different AS_PATH attributes 🍓
all the tuples of type AS_SEQUENCE in the aggregated AS_PATH SHALL show up in every AS_PATH in the initial set of routes being aggregated. the consistency is unmatched 💖
RFC2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.46.235. Routes to be aggregated have different AS_PATH attributes 🌸
all the tuples of type AS_SET in the aggregated AS_PATH SHALL show up in at least one of the AS_PATHs in the initial set. ngl this one is a bit more relaxed, but still a SHALL 🫶
RFC2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.46.236. Routes to be aggregated have different AS_PATH attributes 🧠
ok this one's about ordering. for any AS_SEQUENCE tuple X that comes before tuple Y in the aggregated AS_PATH, X comes before Y in every AS_PATH from the initial set that contains Y, no matter what type Y is. the RFC marks this one as N/A on the keyword side, so nothing capitalised here 🙈
RFC2119: N/A
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: N
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.46.237. Routes to be aggregated have different AS_PATH attributes 💀
no AS_SET tuple with the same value SHALL appear more than once in the aggregated AS_PATH. one and done, periodt 💅
RFC2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.46.238. Routes to be aggregated have different AS_PATH attributes 🎀
multiple AS_SEQUENCE tuples with the same value may appear in the aggregated AS_PATH only when they are adjacent to another tuple of the same type and value. the keyword is N/A here, so it's a lowercase "may" situation 🦋
RFC2119: N/A
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: N
Laurel Y/N/O/Comments: N
NextHop Y/N/O/Comments: Y3.46.239. AS_PATH Aggregation Algorithm 👑
the router needs to be able to perform the (minimum) algorithm described in 9.2.2.2. the SHALL is non-negotiable 💖 (Cisco's comment is iconic: "We don't do merging." 💀)
RFC2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: N We don't do merging.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.46.240. ATOMIC_AGGREGATE ✨
the aggregated route SHALL carry this attribute if at least one of the routes being aggregated has it. main character energy for the attribute 🌟
RFC2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.46.241. AGGREGATOR 🙅♀️
the AGGREGATOR attribute from the routes being aggregated MUST NOT be copied into the aggregated route. absolutely not, we don't do that here 🚫
RFC2119: MUST NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.46.242. AGGREGATOR 🧚♀️
when you aggregate, you can attach a new one (see Section 5.1.7). the keyword here is MAY, so it's optional but very cute 🌈
RFC2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.47. Route Selection Criteria / Section 9.3 [RFC4271] 🦋
3.47.243. Unstable Routes 💜
avoid using them. it's a SHOULD, so please just don't be that person who picks the flaky route 🙈
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.47.244. Route Changes 🍓
you SHOULD NOT make rapid, spontaneous changes to your choice of route. the RFC is literally asking us to not be chaotic 😭
RFC2119: SHOULD NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.48. Originating BGP Routes / Section 9.4 [RFC4271] 🌸
3.48.245. Non-BGP Acquired Routes 🫶
routes that were not acquired via BGP may be distributed to other BGP speakers within the local AS as part of the update process (see Section 9.2). it's a MAY, so totally optional but very social 🧚
RFC2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.48.246. Non-BGP Acquired Routes 🔥
the distribution of these routes SHOULD be controlled via configuration. so the router is asking you to be the boss of it 👑
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.49. BGP Timers / Section 10 [RFC4271] ⏰
3.49.247. Optional Timers 🌈
two optional timers MAY be supported: DelayOpenTimer and IdleHoldTimer, by BGP. vendors really split on this one, and the comments are a whole mood 💅
RFC2119: MAY
Alcatel Y/N/O/Comments: N
Cisco Y/N/O/Comments: O We support DelayOpenTimer but not
IdleHoldTimer
Laurel Y/N/O/Comments: Y support IdleHoldTimer but not the
DelayOpenTimer
NextHop Y/N/O/Comments: Y3.49.248. Hold Time 🎀
the hold time is configurable on a per peer basis, and it's a MUST. no excuses, bestie 🙅♀️
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.49.249. Timers 💖
allow the other timers to be configurable. the keyword is MAY, so it's optional but deeply iconic 🧚♀️
RFC2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.49.250. Jitter 🦋
jitter SHOULD be applied to the timers associated with MinASOriginationInterval, KeepAlive, MinRouteAdvertisementInterval, and ConnectRetry. Cisco only does it for ConnectRetry, which is a whole plot twist 🙈
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: O We only apply to ConnectRetry.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.49.251. Jitter 🌸
apply the same jitter to each of these quantities no matter which destinations the updates go to. so jitter doesn't have to be set up on a "per peer" basis. the keyword is MAY, so it's optional but clean 💅
RFC2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y We apply same only for connectretry.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.49.252. Default Amount of jitter ✨
the jitter is found by multiplying the base value of the timer by a random factor that's uniformly distributed in the range from 0.75 to 1.0. it's a SHALL, so the range is not a vibe, it's a rule 📏
RFC2119: SHALL
Alcatel Y/N/O/Comments: Y Range is 0.9 to 1.1
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.49.253. Default Amount of jitter 🎀
a new random value gets picked each time the timer is set. it's a SHOULD, and it's giving fresh every single time 🔥
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y3.49.254. Jitter Random Value Range 🌈
the range is configurable. the keyword is MAY, so it's a totally optional glow-up 🧚
RFC2119: MAY
Alcatel Y/N/O/Comments: N
Cisco Y/N/O/Comments: N
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: N3.50. TCP Options that May Be Used with BGP / Appendix E [RFC4271] 🌟
3.50.255. TCP PUSH Function Supported 💜
each BGP message SHOULD be transmitted with the PUSH flag set. NextHop marked this as optional, since it depends on TCP stack support. GateD 10 and NGC can run over multiple stacks, which is very cool 🌸
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: O Depends on the TCP stack support.
GateD 10, NGC can run over
multiple stacks.3.50.256. Differentiated Services Code Point (DSCP) Field Support 🦋
TCP connections SHOULD be opened with bits 0-2 of the DSCP field set to 110 (binary). same story as the PUSH flag: NextHop calls it optional because it depends on the TCP stack, and GateD 10 and NGC can run over multiple stacks 🫶
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: O Depends on the TCP stack support.
GateD 10, NGC can run over
multiple stacks.3.51. Reducing Route Flapping / Appendix F.2 [RFC4271] 🦢
3.51.257. Avoid Excessive Route Flapping 🧚
a BGP speaker that needs to withdraw a destination and also send an update about a more specific or less specific route SHOULD combine them into the same UPDATE message. the whole point is to stop the flapping drama before it starts 🙈
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: N
Laurel Y/N/O/Comments: N
NextHop Y/N/O/Comments: N3.52. Complex AS_PATH aggregation / Appendix F.6 [RFC4271] 🌈
3.52.258. Multiple Instances in AS_PATH 💅
when an AS number shows up more than once, the last instance (the rightmost occurrence) of that AS number SHOULD be kept. Alcatel says they use the algorithm in 9.2.2.2 for this, so it's a whole different approach 💖
RFC2119: SHOULD
Alcatel Y/N/O/Comments: N We use algorithm in 9.2.2.2
Cisco Y/N/O/Comments: N
Laurel Y/N/O/Comments: N
NextHop Y/N/O/Comments: N3.53. Security Considerations [RFC4271] 🔐
⚠️ this one is SERIOUS, bestie. not a vibe-check, a must-have. 🫶
3.53.259. Authentication Mechanism 🛡️
a BGP implementation MUST support the authentication mechanism specified in RFC 2385 [RFC2385]. no skipping this, it's the main character requirement for keeping sessions safe 👑
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y4. Additional BGP Implementations Information ✨
okay so three implementations answered the call (5/20/04-6/2/04) for folks who had a BGP implementation but didn't finish the full survey 🫶 here's what they said, bestie 💅
4.1. Avici 🦋
this is the Avici answer to the "hey, could you still send us the answers to these questions" ask 💖
1) BGP product
Contributor (your name):Curtis Villamizar [curtis@fictitious.org]
Company: Avici
name of product: IPriori (TM)
minor version: No interoperability problems with any version.
Current deployed versions are 5.x and 6.0.x.
Version 6.1 and beyond are tested against the
latest BGP specification [RFC4271].
2) What other implementations you interoperate with.
Cisco: IOS 12.0(22)
Juniper: JUNOS (version not given)
3) Do you inter-operate with:
1) Alcatel BGP (release) - not tested
2) cisco BGP IOS 12.0(27)s - not tested
tested with IOS 12.0(22); BGP is the same
3) laurel BGP (specify release) - not tested
4) NextHop GateD - not tested
4) Did the length of the survey for BGP cause you to not
submit the BGP implementation report?
yesso basically: no interop problems with any version 🎀 they're on 5.x and 6.0.x in the wild, and 6.1+ was tested against the latest BGP spec [RFC4271] 🌸 they talk to Cisco and Juniper, and yes, the survey length was the reason they skipped the report 😭
4.2. Data Connection Ltd. 🌈
same ask here, the Data Connection crew answered it like a pro ✨
1) BGP product
Contributor (your name): Mike Dell
Company: Data Connection Ltd.
name of product: DC-BGP
version and minor of software: v1.1
release date: April 2003
2) What other implementations you interoperate with.
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) Do you inter-operate with
1) Alcatel BGP (release) YES
2) cisco BGP IOS 12.0(27)s
Unknown, but we do inter-operate with v12.0(26)s
3) laurel BGP (specify release) Unknown
4) NextHop GateD YES
4) Did the length of the survey for BGP
cause you to not submit the BGP
implementation report?
YESthe list of friends they talk to is LONG 🤩 Alcatel and NextHop GateD are a YES, and for Cisco 12.0(27)s they're unsure, but they do work with 12.0(26)s 💜 and yeah, the survey was too long for them too 💀
4.3. Nokia 🍓
last but not least, the Nokia submission 🧚
1) BGP product
Contributor (your name):Rahul Bahadur
(rahul.bahadur@nokia.com)
Company: Nokia
Name of product: IP Security Platforms
Version and minor of software IPSO 3.8 Build031
Release date May 24, 2004
2) What other implementations you interoperate with.
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) Do you inter-operate with
1) Alcatel BGP (release) - not tested
2) cisco BGP IOS 12.0(27)s - yes
3) laurel BGP (specify release) - not tested
4) NextHop GateD - not tested
4) Did the length of the survey for BGP
cause you to not submit the BGP implementation report?
Yes - lack of resources to help with task.Nokia's answer is giving "we're stretched thin" 🥺 they interop with Cisco 12.0(27)s, and the survey skipped because they didn't have the people power to finish it. valid, honestly 🫶
5. Security Considerations 🔥
okay, this part is short but mighty: this document does not address any security issues 🛡️ so nothing new to see here, but the security stuff lives in [RFC4271] and the rest of the BGP docs, so keep those on your radar 👑
6. Normative References 📚
these are the docs you NEED to read if you're implementing this stuff 💅 full list below, no skipping:
[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. Acknowledgements 🫶
big thank-you to everyone who helped gather these answers 💖 here's who to credit:
Alcatel responses provided by:
Contact Name: Devendra Raut
Contact EMail: Devendra.raut@Alcatel.com
Cisco Systems responses provided by:
Contact Name: Himanshu Shah, Ruchi Kapoor
Contact EMail: hhshah@cisco.com, ruchi@cisco.com
Laurel responses provided by:
Contact Name: Manish Vora
Contact EMail: vora@laurelnetworks.com
NextHop responses provided by:
Contact Name: Susan Hares
Contact EMail: skh@nexthop.com
Additional Help: Matt Richardson, Shane Wright.Authors' Addresses 🎀
these are the people who wrote it, so you know who to slide into the DMs 😌
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.comFull Copyright Statement ⚖️
the legal bit, kept complete 🙈
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Intellectual Property 🦋
the IP rules, also kept complete 💜
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.Acknowledgement 🌸
last bit, and it's a good one 🫶
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).the end, bestie 🎀✨ that's the whole RFC 4276 glow-up 💅
📦 where this page comes from
- ietf: rfc4276 2006-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms