RFC 1105
Border Gateway Protocol (BGP)
RFC 1105: A Border Gateway Protocol (BGP) 🌐✨
Okay bestie, this is RFC 1105, titled A Border Gateway Protocol (BGP) 💖. It's from the Network Working Group and dated June 1989. The authors are K. Lougheed from cisco Systems and Y. Rekhter from the T.J. Watson Research Center at IBM Corp. 🫶 The header doesn't list a category, and it doesn't list anything it obsoletes or updates.
Status of this Memo 🦋
This RFC lays out one specific way to swap network reachability info between Autonomous Systems, and it's giving main character energy 💅
When this was written, BGP implementations already existed for cisco routers and for the NSFNET Nodal Switching Systems 🔥 A public domain version for "gated" was being built at that time.
Distribution of this memo is unlimited 🌈
1. Introduction 🌸
BGP (the Border Gateway Protocol) is an inter-autonomous system routing protocol, so it runs between autonomous systems, not inside one 🧚 It's built on experience with EGP as defined in RFC 904 [1], plus EGP usage on the NSFNET Backbone as described in RFC 1092 [2] and RFC 1093 [3].
The main job of a BGP speaking system is to trade network reachability info with other BGP systems ✨ That info includes which autonomous systems (AS's) your traffic has to transit to reach those networks. It's enough to build a graph of AS connectivity, which means routing loops can get pruned and AS-level policy decisions can get enforced 👑
BGP runs over a reliable transport level protocol, which is honestly so iconic 😭 This means nobody has to implement explicit update fragmentation, retransmission, acknowledgement, or sequencing. Any authentication scheme the transport protocol uses can be used alongside BGP's own authentication mechanisms 🔐
The initial BGP implementation is based on TCP [4], but any reliable transport may be used 🦋 A message passing protocol like VMTP [5] might be more natural for BGP, ngl. TCP will be used anyway, since it's present in virtually all commercial routers and hosts 💜 In the descriptions that follow, "transport protocol connection" can be understood to mean a TCP connection. BGP uses TCP port 179 for establishing its connections 🎀
2. Summary of Operation 💖
Two hosts form a transport protocol connection with each other. They trade messages to open and confirm the connection parameters 🫶 The first data flow is the entire BGP routing table. After that, incremental updates get sent as the routing tables change 🔄 Keepalive messages get sent periodically to make sure the connection is still alive 💓 Notification messages get sent in response to errors or special conditions 🚨 If a connection hits an error condition, a notification message gets sent and the connection is optionally closed 💀
The hosts running the Border Gateway Protocol don't need to be routers, bestie 🙈 A non-routing host could swap routing info with routers via EGP or even an interior routing protocol. That non-routing host could then use BGP to exchange routing info with a border gateway in another autonomous system. The implications and applications of this setup are for further study 🔮
If a particular AS has more than one BGP gateway, then all of those gateways should have a consistent view of routing 👯 The intra-AS routing protocol gives a consistent view of the AS's interior routes. A consistent view of the routes exterior to the AS can be provided in a bunch of different ways 🌷 One way is to use BGP to exchange routing info between the BGP gateways inside a single AS. In that case, to keep the routing info consistent, these gateways MUST have direct BGP sessions with each other (the BGP sessions should form a complete graph) 🫶 This doesn't mean every BGP gateway in a single AS has to have a direct link to every other one. Other methods can be used to keep the routing info consistent too 🧚
3. Message Formats 🎀
This section covers the message formats, plus what to do when errors show up while processing these messages 📝
Messages are sent over a reliable transport protocol connection. A message gets processed only after it's been entirely received. The maximum message size is 1024 bytes, and all implementations are required to support this maximum message size 💅 The smallest message that can be sent is a BGP header with no data portion, which is 8 bytes 🦋
When we say "the BGP connection is closed," we mean the transport protocol connection has been closed and all resources for that BGP connection have been deallocated 🧹 Routing table entries tied to the remote peer get marked as invalid. This info gets passed along to other BGP peers before it's deleted from the system 💜
3.1 Message Header Format 💅
Each message has a fixed size header. There may or may not be a data portion after the header, depending on the message type 🌈 The layout of these fields is shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Marker | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Type | Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Marker: 16 bits 🚦
The Marker field is 16 bits, all ones 💫 It marks the start of a message. If the first two bytes of a message aren't all ones, that's a synchronization error. The BGP connection should be closed after sending a notification message with opcode 5 (connection not synchronized). No notification data is sent in this case 🙅♀️
Length: 16 bits 📏
The Length field is 16 bits. It's the total length of the message, including the header, in bytes 🧮 If an illegal length shows up (more than 1024 bytes or less than 8 bytes), a notification message with opcode 6 (bad message length) and two data bytes of the bad length should be sent, and then the BGP connection gets closed 💅
Version: 8 bits 🔢
The Version field is 8 bits of protocol version number. The current BGP version number is 1 ✨ If a bad version number is found, a notification message with opcode 8 (bad version number) should be sent and the BGP connection closed. The bad version number should be included in one byte of notification data 🙈
Type: 8 bits 🏷️
The Type field is 8 bits of message type code. These are the type codes that are defined:
1 - OPEN
2 - UPDATE
3 - NOTIFICATION
4 - KEEPALIVE
5 - OPEN CONFIRMIf an unrecognized type value shows up, a notification message with opcode 7 (bad type code) should be sent, with data consisting of the byte of the type field in question, and then the BGP connection gets closed 🚫
Hold Timer: 16 bits. ⏳
This field holds the number of seconds that may elapse since receiving a BGP KEEPALIVE or BGP UPDATE message from our BGP peer. Once that time is up, we declare an error and close the BGP connection 💔
3.2 OPEN Message Format 👑
After a transport protocol connection is established, the first message either side sends is an OPEN message 🎉 If the OPEN message is acceptable, an OPEN CONFIRM message gets sent back to confirm it. Once the OPEN is confirmed, UPDATE, KEEPALIVE, and NOTIFICATION messages may be exchanged 💅
On top of the fixed size BGP header, the OPEN message has these fields:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| My Autonomous System | Link Type | Auth. Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authentication Data |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+My Autonomous System: 16 bits 🏠
This field is our 16 bit autonomous system number. If there's a problem with this field, a notification message with opcode 9 (invalid AS field) should be sent and the BGP connection closed. No notification data is sent 🙅♀️
Link Type: 8 bits 🔗
The Link Type field is a single octet containing one of these codes, which define our position in the AS graph relative to our peer 🗺️
0 - INTERNAL
1 - UP
2 - DOWN
3 - H-LINKUP means the peer is higher in the AS hierarchy, DOWN means lower, and H-LINK means same level 🪜 INTERNAL means the peer is another BGP speaking host in our autonomous system. INTERNAL links are used to keep AS routing info consistent with an AS that has multiple border gateways 🫶 If the Link Type field is unacceptable, a notification message with opcode 1 (link type error in open) and data consisting of the expected link type should be sent and the BGP connection closed. The acceptable values for the Link Type fields of two BGP peers are discussed below 📖
Authentication Code: 8 bits 🔐
The Authentication Code field is an octet whose value describes the authentication mechanism in use. A value of 0 means no BGP authentication 🙌 A separate authentication mechanism may be used when establishing the transport level connection. If the authentication code isn't recognized, a notification message with opcode 2 (unknown authentication code) and no data is sent, and the BGP connection is closed 🚫
Authentication Data: variable length 🗝️
The Authentication Data field is variable length and contains authentication data. If the Authentication Code field is 0, the Authentication Data field has zero length ✨ If authentication fails, a notification message with opcode 3 (authentication failure) and no data is sent, and the BGP connection is closed. That's a whole no-vibes moment 😭
3.3 OPEN CONFIRM Message Format ⭐
An OPEN CONFIRM message is sent after receiving an OPEN message 💌 This completes the BGP connection setup. UPDATE, NOTIFICATION, and KEEPALIVE messages may now be exchanged 🎊
An OPEN CONFIRM message is a BGP header with an OPEN CONFIRM type code. There's no data in an OPEN CONFIRM message 🫧
3.4 UPDATE Message Format 🦋
Okay bestie, UPDATE messages are how BGP peers swap routing info 💅 The info in an UPDATE packet can be used to build a graph of how the different autonomous systems are connected 🌸 If you apply the rules we're about to get into, you can spot routing loops and some other weird anomalies and clean them out of the inter-AS routing 🧚
Whenever something goes wrong in an UPDATE message, a notification message gets sent with opcode 4 (bad update) 🚨 It also carries a two byte subcode that explains what went wrong, plus a data field with as much of the UPDATE message's data portion as it can fit 🫶 UPDATE messages look like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gateway |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS count | Direction | AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| repeat (Direction, AS Number) pairs AS count times |
/ /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Net Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| repeat (Network, Metric) pairs Net Count times |
/ /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Gateway: 32 bits.
The Gateway field is the address of a gateway that has routes to the Internet networks listed in the rest of the UPDATE message 🌈 This gateway MUST belong to the same AS as the BGP peer who advertises it 👑 If there's a problem with the gateway field, a notification message with subcode 6 (invalid gateway field) gets sent 💀
AS count: 8 bits.
This field is the count of Direction and AS Number pairs in this UPDATE message 🍓 If an incorrect AS count field shows up, subcode 1 (invalid AS count) is specified in the notification message 🙈
Direction: 8 bits
The Direction field is an octet holding the direction the routing info took when it exited the AS named in the next AS Number field 🦋 These are the values that are defined:
1 - UP (went up a link in the graph)
2 - DOWN (went down a link in the graph)
3 - H_LINK (horizontal link in the graph)
4 - EGP_LINK (EGP derived information)
5 - INCOMPLETE (incomplete information)There's a special provision for passing exterior learned (non-BGP) routes over BGP, and it's lowkey so cute 🎀 If an EGP learned route gets passed over BGP, the Direction field is set to EGP-LINK and the AS Number field is set to the AS number of the EGP peer that advertised the route ✨ All other exterior-learned routes (non-BGP and non-EGP) may be passed by setting the AS Number field to zero and the Direction field to INCOMPLETE 🫶 If the direction code isn't recognized, a notification message with subcode 2 (invalid direction code) is sent 😭
AS Number: 16 bits
This field is the AS number that transmitted the routing info 💜 If there's a problem with this AS number, a notification message with subcode 3 (invalid autonomous system) is sent 🙈
Net Count: 16 bits.
The Net Count field is the number of Metric and Network field pairs that follow it 🧚 If there's a problem with this field, a notification with subcode 7 (invalid net count field) is sent 💅
Network: 32 bits
The Network field is four bytes of Internet network number 🌸 If there's a problem with the network field, a notification message with subcode 8 (invalid network field) is sent 💀
Metric: 16 bits
The Metric field is 16 bits of an unspecified metric, so it's giving mystery ✨ BGP metrics are comparable ONLY if routes have exactly the same AS path 👑 A metric of all ones means the network is unreachable 😭 In every other case the metric field is MEANINGLESS and MUST BE IGNORED 🙈 There are no illegal metric values 💖
3.5 NOTIFICATION Message Format 🚨
NOTIFICATION messages get sent whenever an error condition is detected 💀 The BGP connection gets closed shortly after the notification message goes out 🦋
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode | Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Opcode: 16 bits
The Opcode field describes the type of NOTIFICATION 🌈 These are the opcodes that have been defined:
1 (*) - link type error in open. Data is one byte of proper
link type.
2 (*) - unknown authentication code. No data.
3 (*) - authentication failure. No data.
4 - update error. See below for data description.
5 (*) - connection out of sync. No data.
6 (*) - invalid message length. Data is two bytes of
bad length.
7 (*) - invalid message type. Data is one byte of bad
message type.
8 (*) - invalid version number. Data is one byte of
bad version.
9 (*) - invalid AS field in OPEN. No data.
10 (*) - BGP Cease. No data.The starred opcodes in that list are considered fatal errors, and they cause transport connection termination 🔥
The update error (opcode 4) has 16 bits of subcode as its data, followed by the last UPDATE message in question 🧚 After the subcode comes as much of the data portion of that UPDATE as possible 💖 These are the subcodes that are defined:
1 - invalid AS count
2 - invalid direction code
3 - invalid autonomous system
4 - EGP_LINK or INCOMPLETE_LINK link type at other than
the end of the AS path list
5 - routing loop
6 - invalid gateway field
7 - invalid Net Count field
8 - invalid network fieldData: variable
The Data field contains zero or more bytes of data that help you diagnose why the NOTIFICATION happened 🔍 What's in the Data field depends on the opcode, so check the opcode descriptions above for more details 🫶
3.6 KEEPALIVE Message Format 🫶
BGP doesn't use any transport-protocol-based keepalive mechanism to figure out if peers are reachable 🦋 Instead, KEEPALIVE messages get exchanged between peers often enough that the hold time (as advertised in the BGP header) never expires 💅 A reasonable minimum frequency of KEEPALIVE exchange would be one third of the Hold Time interval ⏰
As soon as the Hold Time associated with a BGP peer has expired, the BGP connection is closed and BGP deallocates all resources associated with that peer 💀
The KEEPALIVE message is just a BGP header without any data 🌸
4. BGP Finite State machine ✨
okay bestie, this section is all about how BGP behaves, described as a Finite State Machine (FSM) 🦋 it's giving state-by-state energy. here's the quick recap of what BGP does in each state. the condensed version lives in Appendix 1 💜
Initially BGP is in the BGP_Idle state.
BGP_Idle state
In this state BGP refuses all incoming BGP connections. No resources are allocated to the BGP neighbor. In response to the Start event (initiated by either system or operator) the local system initializes all BGP resources and changes its state to BGP_Active 🌸
BGP_Active state
In this state BGP is trying to acquire a BGP neighbor by opening a transport protocol connection. If the transport protocol open fails (for example, retransmission timeout), BGP stays in the BGP_Active state 🥺
Otherwise, the local system sends an OPEN message to its peer and changes its state to BGP_OpenSent. Since the hold time of the peer is still undetermined, the hold time is initialized to some large value ⏳
In response to the Stop event (initiated by either system or operator) the local system releases all BGP resources and changes its state to BGP_Idle 🙈
BGP_OpenSent state
In this state BGP waits for an OPEN message from its peer. When an OPEN message is received, all fields are checked for correctness. If the initial BGP header checking detects an error, BGP deallocates all resources associated with this peer and returns to the BGP_Active state. Otherwise, the Link Type, Authentication Code, and Authentication Data fields are checked for correctness 🔍
If the link type is incorrect, a NOTIFICATION message with opcode 1 (link type error in open) is sent. The following combination of link type fields are correct; all other combinations are invalid 👀
Our view Peer view
UP DOWN
DOWN UP
INTERNAL INTERNAL
H-LINK H-LINKIf the link between two peers is INTERNAL, then AS number of both peers must be the same. Otherwise, a NOTIFICATION message with opcode 1 (link type error in open) is sent 💅
If both peers have the same AS number and the link type between these peers is not INTERNAL, then a NOTIFICATION message with opcode 1 (link type error in open) is sent 💀
If the value of the Authentication Code field is zero, any information in the Authentication Data field (if present) is ignored. If the Authentication Code field is non-zero it is checked for known authentication codes. If authentication code is unknown, then the BGP NOTIFICATION message with opcode 2 (unknown authentication code) is sent 🔐
If the Authentication Code value is non-zero, then the corresponding authentication procedure is invoked. The default values are a zero Authentication Code and no Authentication Data 🎀
If any of the above tests detect an error, the local system closes the BGP connection and changes its state to BGP_Idle 🚫
If there are no errors in the BGP OPEN message, BGP sends an OPEN CONFIRM message and goes into the BGP_OpenConfirm state. At this point the hold timer, which was originally set to some arbitrary large value (see above), is replaced with the value indicated in the OPEN message ✨
If disconnect notification is received from the underlying transport protocol or if the hold time expires, the local system closes the BGP connection and changes its state to BGP_Idle 😭
BGP_OpenConfirm state
In this state BGP waits for an OPEN CONFIRM message. As soon as this message is received, BGP changes its state to BGP_Established 🎉 If the hold timer expires before an OPEN CONFIRM message is received, the local system closes the BGP connection and changes its state to BGP_Idle 💔
BGP_Established state
In the BGP_Established state BGP can exchange UPDATE, NOTIFICATION, and KEEPALIVE messages with its peer 👑
If disconnect notification is received from the underlying transport protocol or if the hold time expires, the local system closes the BGP connection and changes its state to BGP_Idle 😤
In response to the Stop event initiated by either the system or operator, the local system sends a NOTIFICATION message with opcode 10 (BGP Cease), closes the BGP connection, and changes its state to BGP_Idle 🌈
5. UPDATE Message Handling 💌
okay so a BGP UPDATE message may be received only in the BGP_Established state. When a BGP UPDATE message is received, each field is checked for validity. When a NOTIFICATION message is sent regarding an UPDATE, the opcode is always 4 (update error), the subcode depends on the type of error, and the rest of the data field is as much as possible of the data portion of the UPDATE that caused the error 🧐
If the Gateway field is incorrect, a BGP NOTIFICATION message is sent with subcode 6 (invalid gateway field). All information in this UPDATE message is discarded 🗑️
If the AS Count field is less than or equal to zero, a BGP NOTIFICATION is sent with subcode 1 (invalid AS count). Otherwise, the complete AS path is extracted and checked as described below 🛤️
If one of the Direction fields in the AS route list is not defined, a BGP NOTIFICATION message is sent with subcode 2 (invalid direction code) 🧭
If one of the AS Number fields in the AS route list is incorrect, a BGP NOTIFICATION message is sent with subcode 3 (invalid autonomous system) 🚨
If either a EGP_LINK or a INCOMPLETE_LINK link type occurs at other than the end of the AS path, a BGP NOTIFICATION message is sent with subcode 4 (EGP_LINK or INCOMPLETE_LINK link type at other than the end of the AS path list) 🙅♀️
If none of the above tests failed, the full AS route is checked for AS loops 🔁
AS loop detection is done by scanning the full AS route and checking that each AS in this route occurs only once. If an AS loop is detected, a BGP NOTIFICATION message is sent with subcode 5 (routing loop) 🌀
If any of the above errors are detected, no further processing is done. Otherwise, the complete AS path is correct and the rest of the UPDATE message is processed 🥳
If the Net Count field is incorrect, a BGP NOTIFICATION message is sent with subcode 7 (invalid Net Count field) 🔢
Each network and metric pair listed in the BGP UPDATE message is checked for a valid network number. If the Network field is incorrect, a BGP Notification message is sent with subcode 8 (invalid network field). No checking is done on the metric field. It is up to a particular implementation to decide whether to continue processing or terminate it upon the first incorrect network 🤷♀️
If the network, its complete AS path, and the gateway are correct, then the route is compared with other routes to the same network. If the new route is better than the current one, then it is flooded to other BGP peers as follows 🌊
- If the BGP UPDATE was received over the INTERNAL link, it is not propagated over any other INTERNAL link. This restriction is due to the fact that all BGP gateways within a single AS form a completely connected graph (see above) 🫶
- Before sending a BGP UPDATE message over the non-INTERNAL links, check the AS path to insure that doing so would not cause a routing loop. The BGP UPDATE message is then propagated (subject to the local policy restrictions) over any non-INTERNAL link over which a routing loop would not result 🧠
- If the BGP UPDATE message is propagated over a non-INTERNAL link, then the current AS number and link type of the link over which it is going to be propagated is prepended to the full AS path and the AS count field is incremented by 1. If the BGP UPDATE message is propagated over an INTERNAL link, then the full AS path is passed unmodified and the AS count stays the same. The Gateway field is replaced with the sender's own address 💖
6. Acknowledgements 🫶
we would like to express our thanks to Len Bosack (cisco Systems), Jeff Honig (Cornell University) and all members of the IWG task force for their contributions to this document 🌸
Appendix 1 ✨
BGP FSM State Transitions and Actions ✨
Okay bestie, this is the part where we watch the BGP FSM hop between states every time something happens 🦋. Here's the full cast of states and events:
BGP States:
1 - BGP_Idle
2 - BGP_Active
3 - BGP_OpenSent
4 - BGP_OpenConfirm
5 - BGP_Established
BGP Events:
1 - BGP Start
2 - BGP Transport connection open
3 - BGP Transport connection closed
4 - BGP Transport connection open failed
5 - Receive OPEN message
6 - Receive OPEN CONFIRM message
7 - Receive KEEPALIVE message
8 - Receive UPDATE messages
9 - Receive NOTIFICATION message
10 - Holdtime timer expired
11 - KeepAlive timer expired
12 - Receive CEASE message
13 - BGP StopNext up is the big state transition table 💅. It shows, for each state and event, what actions fire, what message gets sent (if any), and which state you land in next. The state you're in is the heading, and each event goes under it.
Event Actions Message Sent Next State
--------------------------------------------------------------------
BGP_Idle (1)
1 Initialize resources none 2
BGP_Active (2)
2 Initialize resources OPEN 3
4 none none 2
13 Release resources none 1
BGP_OpenSent(3)
3 none none 1
5 Process OPEN is OK OPEN CONFIRM 4
Process OPEN Message failed NOTIFICATION 1
11 Restart KeepAlive timer KEEPALIVE 3
13 Release resources none 1
BGP_OpenConfirm (4)
6 Complete initialization none 5
3 none none 1
10 Close transport connection none 1
11 Restart KeepAlive timer KEEPALIVE 4
13 Release resources none 1
BGP_Established (5)
7 Process KEEPALIVE none 5
8 Process UPDATE is OK UPDATE 5
Process UPDATE failed NOTIFICATION 5
9 Process NOTIFICATION none 5
10 Close transport connection none 1
11 Restart KeepAlive timer KEEPALIVE 5
12 Close transport connection NOTIFICATION 1
13 Release resources none 1
--------------------------------------------------------------------Now the rule for everything else 💀. Any state-event combo that isn't in the table is a fatal error. When that happens, the BGP transport connection gets terminated (if necessary) and the FSM transitions to BGP_Idle. Wild, but that's the deal.
If the big table feels like too much, there's a condensed version 🌸. Same info, just squished into a grid where the rows are events and the columns are states:
Events|BGP_Idle BGP_Active BGP_OpenSent BGP_OpenConfirm BGP_Estab
| (1) | (2) | (3) | (4) | (5)
|-------------------------------------------------------------
1 | 2 | | | |
| | | | |
2 | | 3 | | |
| | | | |
3 | | | 1 | 1 |
| | | | |
4 | | 2 | | |
| | | | |
5 | | | 4 or 1 | |
| | | | |
6 | | | | 5 |
| | | | |
7 | | | | | 5
| | | | |
8 | | | | | 5
| | | | |
9 | | | | | 5
| | | | |
10 | | | | 1 | 1
| | | | |
11 | | | 3 | 4 | 5
| | | | |
12 | | | | | 1
| | | | |
13 | | 1 | 1 | 1 | 1
| | | | |
--------------------------------------------------------------References
- [1] Mills, D., "Exterior Gateway Protocol Formal Specification", RFC 904, BBN, April 1984. 📚
- [2] Rekhter, Y., "EGP and Policy Based Routing in the New NSFNET Backbone", RFC 1092, T. J. Watson Research Center, February 1989. 📚
- [3] Braun, H-W., "The NSFNET Routing Architecture", RFC 1093, MERIT/NSFNET Project, February 1989. 📚
- [4] Postel, J., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", RFC 793, DARPA, September 1981. 📚
- [5] Cheriton, D., "VMTP: Versatile Message Transaction Protocol", RFC 1045, Stanford University, February 1988. 📚
Authors' Addresses 🫶
The two legends who wrote this one 🌈:
Kirk Lougheed
cisco Systems, Inc.
1360 Willow Road, Suite 201
Menlo Park, CA 94025
Phone: (415) 326-1941
Email: LOUGHEED@MATHOM.CISCO.COMJacob Rekhter
T.J. Watson Research Center
IBM Corporation
P.O. Box 218
Yorktown Heights, NY 10598
Phone: (914) 945-3896
Email: YAKOV@IBM.COM📦 where this page comes from
- ietf: rfc1105 1989-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms