RFC 6396
Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format
Part 1 of 7 💖
RFC 6396: Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format 🎀
Authors: L. Blunk and M. Karir (Merit Network), C. Labovitz (Deepfield Networks) 👯♀️ Category: Standards Track 📜 Date: October 2011 📅 ISSN: 2070-1721 Obsoletes / Updates: none listed in the header 🫶
Abstract ✨
okay so this doc describes the MRT format for exporting routing information 🦋 It was made alongside the Multi-threaded Routing Toolkit (MRT), which is where the format gets its name. The format can export routing protocol messages, state changes, and routing information base contents 💅
Status of This Memo 🌸
This is an Internet Standards Track document, so it's officially a standard. 👑
It's a product of the Internet Engineering Task Force (IETF), and it reflects the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 5741 📚
For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6396 🧚
Copyright Notice 🌈
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 💜
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read those, because they spell out your rights and restrictions for this document 🙈 Code Components pulled from this document have to include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 🔥
This doc may include material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. Some folks who hold the copyright in that older material may not have let the IETF Trust allow modifications outside the IETF Standards Process 💀 So unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works may not be created outside it either. The one exceptions are formatting it for publication as an RFC or translating it into languages other than English 🍓
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Specification of Requirements . . . . . . . . . . . . . . 4
2. MRT Common Header . . . . . . . . . . . . . . . . . . . . . . 4
3. Extended Timestamp MRT Header . . . . . . . . . . . . . . . . 5
4. MRT Types . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. OSPFv2 Type . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. TABLE_DUMP Type . . . . . . . . . . . . . . . . . . . . . 7
4.3. TABLE_DUMP_V2 Type . . . . . . . . . . . . . . . . . . . . 9
4.3.1. PEER_INDEX_TABLE Subtype . . . . . . . . . . . . . . . 9
4.3.2. AFI/SAFI-Specific RIB Subtypes . . . . . . . . . . . . 11
4.3.3. RIB_GENERIC Subtype . . . . . . . . . . . . . . . . . 11
4.3.4. RIB Entries . . . . . . . . . . . . . . . . . . . . . 12
4.4. BGP4MP Type . . . . . . . . . . . . . . . . . . . . . . . 13
4.4.1. BGP4MP_STATE_CHANGE Subtype . . . . . . . . . . . . . 13
4.4.2. BGP4MP_MESSAGE Subtype . . . . . . . . . . . . . . . . 14
4.4.3. BGP4MP_MESSAGE_AS4 Subtype . . . . . . . . . . . . . . 15
4.4.4. BGP4MP_STATE_CHANGE_AS4 Subtype . . . . . . . . . . . 15
4.4.5. BGP4MP_MESSAGE_LOCAL Subtype . . . . . . . . . . . . . 16
4.4.6. BGP4MP_MESSAGE_AS4_LOCAL Subtype . . . . . . . . . . . 16
4.5. ISIS Type . . . . . . . . . . . . . . . . . . . . . . . . 16
4.6. OSPFv3 Type . . . . . . . . . . . . . . . . . . . . . . . 17
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
5.1. Type Codes . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2. Subtype Codes . . . . . . . . . . . . . . . . . . . . . . 18
5.3. Defined Type Codes . . . . . . . . . . . . . . . . . . . . 18
5.4. Defined BGP, BGP4PLUS, and BGP4PLUS_01 Subtype Codes . . . 19
5.5. Defined TABLE_DUMP Subtype Codes . . . . . . . . . . . . . 19
5.6. Defined TABLE_DUMP_V2 Subtype Codes . . . . . . . . . . . 19
5.7. Defined BGP4MP and BGP4MP_ET Subtype Codes . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Normative References . . . . . . . . . . . . . . . . . . . 21
7.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. MRT Encoding Examples . . . . . . . . . . . . . . . . 23
Appendix B. Deprecated MRT Types . . . . . . . . . . . . . . . . 26
B.1. Deprecated MRT Informational Types . . . . . . . . . . . . 26
B.1.1. NULL Type . . . . . . . . . . . . . . . . . . . . . . 26
B.1.2. START Type . . . . . . . . . . . . . . . . . . . . . . 27
B.1.3. DIE Type . . . . . . . . . . . . . . . . . . . . . . . 27
B.1.4. I_AM_DEAD Type . . . . . . . . . . . . . . . . . . . . 27
B.1.5. PEER_DOWN Type . . . . . . . . . . . . . . . . . . . . 27
B.2. Other Deprecated MRT Types . . . . . . . . . . . . . . . . 27
B.2.1. BGP Type . . . . . . . . . . . . . . . . . . . . . . . 27
B.2.2. RIP Type . . . . . . . . . . . . . . . . . . . . . . . 30
B.2.3. IDRP Type . . . . . . . . . . . . . . . . . . . . . . 30
B.2.4. RIPNG Type . . . . . . . . . . . . . . . . . . . . . . 31
B.2.5. BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . 31
B.2.6. Deprecated BGP4MP Subtypes . . . . . . . . . . . . . . 32
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 341. Introduction ✨
Researchers and engineers really love studying network behavior by looking at routing protocol transactions and routing information base snapshots 🔍 That's why the MRT record format exists: it wraps up, exports, and archives this info in a standardized data representation 📦
BGP in particular has been studied and analyzed to death, and the MRT format has been a huge help with that 💅 Two big MRT-based BGP archive projects are the University of Oregon Route Views Project and the RIPE NCC Routing Information Service (RIS) 🌍
The MRT format was first defined in the MRT Programmer's Guide [MRT_PROG_GUIDE]. Later extensions came from the GNU Zebra software routing suite and the Sprint Advanced Technology Labs Python Routing Toolkit (PyRT) 🧚 More extensions may show up later by defining new values for the MRT Type and Subtype fields 🦋
Some MRT record types in the MRT Programmer's Guide [MRT_PROG_GUIDE] aren't known to have ever been implemented, and some were only partly specified 🙈 Also, a few types were used in early MRT implementations but barely got used, then got replaced by better versions 💀 These are considered deprecated and are covered in Deprecated MRT Types (Appendix B) at the end of this document. The deprecated types are codes 0 through 10 inclusive. Researchers digging through old MRT archives might still find some of them interesting 🍓
Fields with multi-octet numeric values are encoded in network octet order, from most significant octet to least significant octet 🔢 Fields that carry routing message fields are encoded in the same order they appear in the packet contents 🫶
1.1. Specification of Requirements 📜
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. MRT Common Header 🎀
Every MRT format record starts with a Common Header made up of a Timestamp, Type, Subtype, and Length field 🌸 The header is followed by a Message field. The MRT Common Header looks 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Subtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: MRT Common HeaderHere's what each header field means 🧁
Timestamp: This is a 4-octet field holding the number of seconds elapsed since midnight proleptic Coordinated Universal Time (UTC), not counting leap seconds. This representation of time is sometimes called "UNIX time" [POSIX]. ⏰ Be warned that this format can't represent anything before January 1, 1970 🙅♀️ The latest UTC time a 4-octet integer can hold is 03:14:07 on January 19, 2038, which is the hexadecimal value 7FFFFFFF 😭 Implementations that want to make MRT records after that date will need to supply an alternate EPOCH time base for the Timestamp field 🔥 How to signal that alternate EPOCH is currently outside the scope of this document 🚧
Type: This is a 2-octet field that says what kind of information is in the Message field. Types 0 through 4 are informational messages about the state of an MRT collector, while Types 5 and higher carry routing information 👑
Subtype: This is a 2-octet field that helps tell apart message information within a particular record Type 🦋
Length: This is a 4-octet message length field. It holds the number of octets in the message, and it does not count the length of the MRT Common Header 🧮
Message: This is a variable-length message, and what's inside depends on the Type and Subtype fields 🌈
3. Extended Timestamp MRT Header ✨
okay so a bunch of MRT record types come in a variant with an extended timestamp field 🕰️ the whole point is letting people measure stuff at sub-second resolution, which is giving precision bestie 💖 This field is called Microsecond Timestamp. It's an unsigned 32BIT offset in microseconds, and it gets added on top of the Timestamp field value. The Timestamp field itself stays exactly as it's defined in the MRT Common Header, no changes there 🙅♀️
The Microsecond Timestamp sits right after the Length field in the MRT Common Header and comes before every other field in the message. It also counts toward the Length field value, so don't forget it 🧮 Here's the Extended Timestamp MRT Header, iykyk:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Subtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Microsecond Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Extended Timestamp MRT Header4. MRT Types 🎀
The following MRT Types are currently defined for the MRT format. Types with the "_ET" suffix in their names are the ones that use an Extended Timestamp MRT Header 🦋 Their Subtype and Message fields stay exactly as they're defined for the MRT Types of the same name without the "_ET" suffix.
11 OSPFv2
12 TABLE_DUMP
13 TABLE_DUMP_V2
16 BGP4MP
17 BGP4MP_ET
32 ISIS
33 ISIS_ET
48 OSPFv3
49 OSPFv3_ET4.1. OSPFv2 Type 🦋
This type supports the OSPFv2 protocol as defined in RFC 2328 [RFC2328]. It's used to encode the exchange of OSPF protocol packets 📦
The MRT Message field for the OSPFv2 Type is laid out 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Message Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: OSPFv2 TypeThe Remote IP Address field holds the Source IPv4 [RFC0791] address from the IP header of the OSPF message. The Local IP Address holds the Destination IPv4 address from that same IP header 👀 And the OSPF Message Contents field has the complete contents of the OSPF packet that comes after the IP header. Full packet, no cuts ✨
4.2. TABLE_DUMP Type 🌸
The TABLE_DUMP Type is used to encode the contents of a BGP Routing Information Base (RIB). Each RIB entry gets its own distinct sequential MRT record. Real talk: it is RECOMMENDED that new MRT encoding implementations use the TABLE_DUMP_V2 Type (see below) instead of this one, because this type has limitations 🙃 Still, there's a huge pile of historical data encoded with this type, so MRT decoding applications MAY wish to support it anyway 📚
The Subtype field tells you whether the RIB entry has IPv4 or IPv6 [RFC2460] addresses. There are two possible values:
1 AFI_IPv4
2 AFI_IPv6The TABLE_DUMP Type looks 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| View Number | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originated Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP Address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS | Attribute Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Attribute... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: TABLE_DUMP TypeThe View Number field is normally 0. It's meant for situations where an implementation has multiple RIB views, like a route server 🖥️ When multiple RIB views are around, an implementation MAY use the View Number field to tell apart the entries from each view. The Sequence Number field is a simple incremental counter for each RIB entry. A typical RIB dump is going to blow past the 16-bit bounds of this counter, and in that case an implementation SHOULD simply wrap back to zero and keep counting 🔄
The Prefix field has the IP address of a particular RIB entry. How big it is depends on the Subtype for the record. AFI_IPv4 means an Address Family Identifier (AFI) type of IPv4 [IANA-AF], and the Prefix field is 4 octets long. For AFI_IPv6, it's 16 octets. The Prefix Length field tells you the length in bits of the prefix mask for the Prefix field right before it 🎯
The Status octet is unused in the TABLE_DUMP Type and SHOULD be set to 1. Unused, but still set to 1, bestie 🤷♀️
The Originated Time holds the 4-octet time at which this prefix was heard. The value is the number of seconds since 1 January 1970 00:00:00 UTC ⏰
The Peer IP Address field is the IP address of the peer that sent the update for this RIB entry. Just like the Prefix field, its size depends on the Subtype. AFI_IPv4 gets a 4-octet field with an IPv4 address, while AFI_IPv6 needs a 16-octet field with an IPv6 address. The Peer AS field is the 2-octet Autonomous System (AS) number of the peer 🌐
The TABLE_DUMP Type does not permit 4-byte Peer AS numbers, and it doesn't let the AFI of the peer IP differ from the AFI of the Prefix field. The TABLE_DUMP_V2 Type MUST be used in these situations. No exceptions, no vibes-based workarounds 🚫
Attribute Length holds the length of the Attribute field and is 2 octets. The BGP Attribute field has the BGP attribute information for the RIB entry. Here's the tea ☕ The AS_PATH attribute MUST only consist of 2-byte AS numbers. TABLE_DUMP_V2 is the one that supports 4-byte AS numbers in the AS_PATH attribute 💅
4.3. TABLE_DUMP_V2 Type 💜
The TABLE_DUMP_V2 Type is the glow-up of the TABLE_DUMP Type ✨ It adds 4-byte Autonomous System Number (ASN) support and full support for BGP multiprotocol extensions. It also gets way more space efficient by using an index table for peers and allowing a single MRT record per Network Layer Reachability Information (NLRI) entry. These are the subtypes used with the TABLE_DUMP_V2 Type:
1 PEER_INDEX_TABLE
2 RIB_IPV4_UNICAST
3 RIB_IPV4_MULTICAST
4 RIB_IPV6_UNICAST
5 RIB_IPV6_MULTICAST
6 RIB_GENERIC4.3.1. PEER_INDEX_TABLE Subtype 🧚
An initial PEER_INDEX_TABLE MRT record gives you the BGP ID of the collector, an OPTIONAL view name, and a list of indexed peers 📋 After the PEER_INDEX_TABLE MRT record, you get a series of MRT records that encode the RIB table entries. That series uses subtypes 2-6 and is separate from the PEER_INDEX_TABLE MRT record itself, and each one includes full MRT record headers. The RIB entry MRT records MUST immediately follow the PEER_INDEX_TABLE MRT record, no detours 🚗💨
The header of the PEER_INDEX_TABLE Subtype looks like this. The View Name is OPTIONAL, and if it isn't there, the View Name Length MUST be set to 0. The View Name encoding MUST follow the UTF-8 transformation format [RFC3629] 🌈
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Collector BGP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| View Name Length | View Name (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Count | Peer Entries (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: PEER_INDEX_TABLE SubtypeThe format of the Peer Entries is shown below. The PEER_INDEX_TABLE record holds Peer Count number of Peer Entries 🫶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer BGP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP Address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Peer EntriesThe Peer Type, Peer BGP ID, Peer IP Address, and Peer AS fields get repeated as many times as the Peer Count field says. The position of the peer in the PEER_INDEX_TABLE is used as an index in the later TABLE_DUMP_V2 MRT records. The index number starts at 0 🔢
The Peer Type field is a bit field that tells you the type of the AS and the IP address, which are identified by the A and I bits respectively:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| | | | | | |A|I|
+-+-+-+-+-+-+-+-+
Bit 6: Peer AS number size: 0 = 16 bits, 1 = 32 bits
Bit 7: Peer IP Address family: 0 = IPv4, 1 = IPv6
Figure 7: Peer Type FieldThe MRT records that follow the PEER_INDEX_TABLE MRT record use the subtypes listed below, and they contain the actual RIB table entries 📦 Each one has a header that specifies a sequence number, an NLRI field, and a count of the number of RIB entries inside the record. That's the whole vibe ✨
4.3.2. AFI/SAFI-Specific RIB Subtypes ✨
okay so the AFI/SAFI-specific RIB Subtypes are RIB_IPV4_UNICAST, RIB_IPV4_MULTICAST, RIB_IPV6_UNICAST, and RIB_IPV6_MULTICAST 💅 they get their very own TABLE_DUMP_V2 subtypes bc they're the most common kind of RIB table instances, and giving them dedicated subtypes makes the encodings way more compact 🦋 these subtypes also let one MRT record hold multiple RIB table entries for a single prefix, which is so efficient 🔥
the Prefix Length and Prefix fields are encoded the same way the BGP NLRI encoding does it for IPv4 and IPv6 prefixes 🌸 basically, the Prefix field holds the address prefix, then enough trailing bits to make the end of the field land on an octet boundary. the value of those trailing bits is irrelevant, so don't stress about them 🙈
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Entry Count | RIB Entries (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 8: RIB Entry Header 🎀
4.3.3. RIB_GENERIC Subtype 🧚
the RIB_GENERIC header is shown below! it's used to cover RIB entries that don't fall under the common case entries we just talked about 💜 it's made up of an AFI, a Subsequent AFI (SAFI), and a single NLRI entry. the NLRI info is specific to whatever AFI and SAFI values you've got 🌈
and here's the important bit 👑 an implementation that doesn't recognize particular AFI and SAFI values SHOULD discard the remainder of the MRT record. no cap, that's the move if you don't know the values 💀
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family Identifier |Subsequent AFI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Layer Reachability Information (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Entry Count | RIB Entries (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 9: RIB_GENERIC Entry Header 🦋
4.3.4. RIB Entries 💖
the RIB Entries get repeated Entry Count times 🔁 they all share a common format, shown below. each one includes a Peer Index from the PEER_INDEX_TABLE MRT record, an originated time for the RIB Entry, and the BGP path attribute length plus the attributes themselves ✨
one thing that is NOT optional 🙅♀️ all AS numbers in the AS_PATH attribute MUST be encoded as 4-byte AS numbers. full stop, periodt 💅
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originated Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Attributes... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 10: RIB Entries 🌸
there is one exception to the encoding of BGP attributes, and it's for the BGP MP_REACH_NLRI attribute (BGP Type Code 14) [RFC4760] 🧩 since the AFI, SAFI, and NLRI info is already encoded in the RIB Entry Header or the RIB_GENERIC Entry Header, only the Next Hop Address Length and Next Hop Address fields are included. the Reserved field gets omitted, and the attribute length is adjusted to reflect only the length of the Next Hop Address Length and Next Hop Address fields. no duplicate info, iconic 🫶
4.4. BGP4MP Type 🌈
this type was initially defined in the Zebra software package for the BGP protocol with multiprotocol extension support, as defined by RFC 4760 [RFC4760] 🍓 the BGP4MP Type has six Subtypes:
0 BGP4MP_STATE_CHANGE
1 BGP4MP_MESSAGE
4 BGP4MP_MESSAGE_AS4
5 BGP4MP_STATE_CHANGE_AS4
6 BGP4MP_MESSAGE_LOCAL
7 BGP4MP_MESSAGE_AS4_LOCAL4.4.1. BGP4MP_STATE_CHANGE Subtype 🦋
this message is used to encode state changes in the BGP finite state machine (FSM) 🔄 the BGP FSM states are encoded in the Old State and New State fields, which show the previous and current state. in some cases the Peer AS Number may be undefined, and in those cases the value of this field MAY be set to zero 🙈 here's how it looks:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS Number | Local AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP Address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP Address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old State | New State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 11: BGP4MP_STATE_CHANGE Subtype 💜
the FSM states are defined in RFC 4271 [RFC4271], Section 8.2.2 📖 both the Old State value and the New State value are encoded as 2-octet numbers, and the state values are defined numerically like this:
1 Idle
2 Connect
3 Active
4 OpenSent
5 OpenConfirm
6 Establishedthe BGP4MP_STATE_CHANGE message also has Interface Index and Address Family fields ✨ the Interface Index gives the interface number of the peering session. the index value is OPTIONAL and MAY be zero if it's unknown or unsupported 🤷♀️ the Address Family tells you what types of addresses are in the address fields. at present, these AFI Types are supported:
1 AFI_IPv4
2 AFI_IPv64.4.2. BGP4MP_MESSAGE Subtype 💌
this subtype is used to encode BGP messages, and it can encode any Type of BGP message 📨 the entire BGP message gets encapsulated in the BGP Message field, including the 16-octet marker, the 2-octet length, and the 1-octet type fields. the BGP4MP_MESSAGE Subtype does NOT support 4-byte AS numbers 😭 the AS_PATH contained in these messages MUST only consist of 2-byte AS numbers. the BGP4MP_MESSAGE_AS4 Subtype updates this one to support 4-byte AS numbers. here are the BGP4MP_MESSAGE 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS Number | Local AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP Address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP Address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Message... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 12: BGP4MP_MESSAGE Subtype 🦋
the Interface Index gives the interface number of the peering session. the index value is OPTIONAL and MAY be zero if it's unknown or unsupported 🫶 the Address Family tells you what types of addresses are in the subsequent address fields. at present, these AFI Types are supported:
1 AFI_IPv4
2 AFI_IPv6the Address Family value only applies to the IP addresses contained in the MRT header 💅 otherwise the BGP4MP_MESSAGE Subtype is transparent to the contents of the actual message, which can contain any valid AFI/SAFI values. and one rule that's non-negotiable: only one BGP message SHALL be encoded in the BGP4MP_MESSAGE Subtype 👑
4.4.3. BGP4MP_MESSAGE_AS4 Subtype 🌸
this subtype updates the BGP4MP_MESSAGE Subtype to support 4-byte AS numbers ✨ otherwise it's identical to the BGP4MP_MESSAGE Subtype. the AS_PATH in these messages MUST only consist of 4-byte AS numbers 🔥 here are the BGP4MP_MESSAGE_AS4 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP Address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP Address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Message... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 13: BGP4MP_MESSAGE_AS4 Subtype ✨
4.4.4. BGP4MP_STATE_CHANGE_AS4 Subtype ✨
okay so this subtype is basically the BGP4MP_STATE_CHANGE one with a glow-up for 4-byte AS numbers 💅 the BGP FSM states still go in the Old State and New State fields to show the previous and current state 🦋 the only real change is that the Peer and Local AS Number fields get stretched to 4 bytes. everything else is identical, bestie 💖 here's the layout:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP Address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP Address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old State | New State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 14: BGP4MP_STATE_CHANGE_AS4 Subtype
4.4.5. BGP4MP_MESSAGE_LOCAL Subtype 🌈
so MRT has mostly been about collecting BGP messages that came from somewhere else, like a passive route collector 👀 but active BGP implementations? they'd love to archive the messages they generate locally too 🧚 that's what this subtype is for: flagging a locally generated BGP message.
the fields are the same as BGP4MP_MESSAGE, including the Peer and Local IP and AS fields. the Local fields still point to the local IP and AS number of the collector that made the message, and the Peer IP and AS fields point to whoever received it 💜
4.4.6. BGP4MP_MESSAGE_AS4_LOCAL Subtype 🍓
same energy as BGP4MP_MESSAGE_LOCAL since it's also about locally generated messages 🫶 the fields match the BGP4MP_MESSAGE_AS4 message type exactly, so if you know one, you know both 💅
4.5. ISIS Type 🛤️
this type supports the IS-IS routing protocol, as defined in RFC 1195 [RFC1195] 🌸 there's no Type-specific header for the ISIS Type, and the Subtype code for this type is undefined. the ISIS PDU just sits right after the MRT Common Header fields, no extra fuss ✨
4.6. OSPFv3 Type 🦋
the OSPFv3 Type glows up the original OSPFv2 Type so it can handle IPv6 addresses for the OSPFv3 protocol, as defined in RFC 5340 [RFC5340] 💖 here's how the MRT Message field is laid out for it:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote IP Address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP Address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Message Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 15: OSPFv3 Type
5. IANA Considerations 📋
this section is the guidance for IANA about registering values related to the MRT spec, following BCP 26, RFC 5226 [RFC5226] 💅
there are two name spaces in MRT that have been registered: Type Codes and Subtype Codes. both are 16 bits long each ✨
MRT is not intended as a general-purpose specification for protocol information export, and allocations should not be made for purposes unrelated to routing protocol information export. so don't go registering random stuff here, bestie 🙅♀️
the following policies are used here with the meanings defined in BCP 26: "Specification Required", "IETF Consensus", "Experimental Use", "First Come First Served". assignments consist of a name and the value 🎀
5.1. Type Codes 🔢
Type Codes have a range from 0 to 65535, and 0-64 are reserved 🧚 New Type Codes MUST be allocated starting at 65. Type Codes 65-511 are assigned by IETF Review. Type Codes 512-2047 are assigned based on Specification Required. Type Codes 2048-64511 are available on a First Come First Served policy. Type Codes 64512 - 65534 are available for Experimental Use. The Type Code Value 65535 is reserved 💜
5.2. Subtype Codes 🍬
Subtype Codes have a range from 0 to 65535. Subtype definitions are specific to a particular Type Code definition. New Subtype Code definitions must reference an existing Type Code to which the Subtype belongs. Subtype assignments follow the assignment rules for the Type Codes to which they belong 🌸
5.3. Defined Type Codes 🗂️
this document defines the following message Type Codes:
Name Value Definition
---- ----- ----------
NULL 0 See Appendix B.1.1
START 1 See Appendix B.1.2
DIE 2 See Appendix B.1.3
I_AM_DEAD 3 See Appendix B.1.4
PEER_DOWN 4 See Appendix B.1.5
BGP 5 See Appendix B.2.1
RIP 6 See Appendix B.2.2
IDRP 7 See Appendix B.2.3
RIPNG 8 See Appendix B.2.4
BGP4PLUS 9 See Appendix B.2.5
BGP4PLUS_01 10 See Appendix B.2.5
OSPFv2 11 See Section 4.1
TABLE_DUMP 12 See Section 4.2
TABLE_DUMP_V2 13 See Section 4.3
BGP4MP 16 See Section 4.4
BGP4MP_ET 17 See Section 4.4
ISIS 32 See Section 4.5
ISIS_ET 33 See Section 4.5
OSPFv3 48 See Section 4.6
OSPFv3_ET 49 See Section 4.65.4. Defined BGP, BGP4PLUS, and BGP4PLUS_01 Subtype Codes 🧩
this document defines the following message Subtype Codes for the BGP, BGP4PLUS, and BGP4PLUS_01 Types:
Name Value Definition
---- ----- ----------
BGP_NULL 0 See Appendix B.2.1
BGP_UPDATE 1 See Appendix B.2.1
BGP_PREF_UPDATE 2 See Appendix B.2.1
BGP_STATE_CHANGE 3 See Appendix B.2.1
BGP_SYNC 4 See Appendix B.2.1
BGP_OPEN 5 See Appendix B.2.1
BGP_NOTIFY 6 See Appendix B.2.1
BGP_KEEPALIVE 7 See Appendix B.2.15.5. Defined TABLE_DUMP Subtype Codes 📊
this document defines the following message Subtype Codes for the TABLE_DUMP Type:
Name Value Definition
---- ----- ----------
AFI_IPv4 1 See Section 4.2
AFI_IPv6 2 See Section 4.25.6. Defined TABLE_DUMP_V2 Subtype Codes 🎀
this document defines the following message Subtype Codes for the TABLE_DUMP_V2 Type:
Name Value Definition
---- ----- ----------
PEER_INDEX_TABLE 1 See Section 4.3
RIB_IPV4_UNICAST 2 See Section 4.3
RIB_IPV4_MULTICAST 3 See Section 4.3
RIB_IPV6_UNICAST 4 See Section 4.3
RIB_IPV6_MULTICAST 5 See Section 4.3
RIB_GENERIC 6 See Section 4.35.7. Defined BGP4MP and BGP4MP_ET Subtype Codes 🦋
this document defines the following message Subtype Codes for the BGP4MP Type:
Name Value Definition
---- ----- ----------
BGP4MP_STATE_CHANGE 0 See Section 4.4
BGP4MP_MESSAGE 1 See Section 4.4
BGP4MP_ENTRY 2 See Section 4.4
BGP4MP_SNAPSHOT 3 See Section 4.4
BGP4MP_MESSAGE_AS4 4 See Section 4.4
BGP4MP_STATE_CHANGE_AS4 5 See Section 4.4
BGP4MP_MESSAGE_LOCAL 6 See Section 4.4
BGP4MP_MESSAGE_AS4_LOCAL 7 See Section 4.46. Security Considerations 🔐
okay the security part is serious business, bestie 😭 the MRT Format stores routing protocol information data. the fields in the MRT spec are descriptive, meaning they're there to help with analysing routing data 📈 so the fields defined right now don't create extra security risks by themselves, because the recipient app doesn't use them to trigger any particular behavior ✨
BUT some info inside an MRT data structure might be sensitive or private 🙈 for example, a BGP peer sending a message to an MRT-enabled router might NOT expect that message to get shared beyond the AS it was sent to.
Info that could count as sensitive includes BGP peer IP addresses, BGP Next Hop IP addresses, and BGP Path Attributes. this stuff could be really useful for mounting attacks against the BGP protocol and routing infrastructure 💀 RFC 4272 [RFC4272] digs into a bunch of weaknesses in BGP that could potentially get exploited.
an organization that wants to use the MRT structure to export routing information beyond the domain where it's normally accessible (for example, publishing MRT dumps for researchers) should verify with any peers whose information might be included, and possibly remove sensitive fields 🫶 don't skip this, it's giving responsibility.
and the proposed geolocation extension to MRT could reveal the location of an MRT router's peers [GEOMRT] 😱 yikes, periodt.
7. References 📚
7.1. Normative References ✨
okay so these are the docs you literally have to read to implement this stuff, no cap 📚
[IANA-AF]IANA, "Address Family Numbers",<http://www.iana.org/numbers.html>.[RFC0791]Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.[RFC1195]Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[RFC2328]Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.[RFC2460]Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.[RFC3629]Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.[RFC4271]Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.[RFC4760]Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.[RFC5226]Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.[RFC5340]Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
7.2. Informative References 💅
these ones are super helpful for context but they're not the core rules, so think of them as bonus reading 🧚
[GEOMRT]Manderson, T., "Multi-Threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) Routing Information Export Format with Geo-Location Extensions", RFC 6397, October 2011.[MRT_PROG_GUIDE]Labovitz, C., "MRT Programmer's Guide", November 1999,<http://www.merit.edu/networkresearch/mrtprogrammer.pdf>.[POSIX]Institute of Electrical and Electronics Engineers, "P1003.1, Information Technology Portable Operating System Interface (POSIX) Part 1: System Application Program Interface (API) [C Language], 1990.", IEEE Standard P1003.1.[RFC2080]Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997.[RFC2453]Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.[RFC4272]Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, January 2006.
Appendix A. MRT Encoding Examples 🎀
okay this appendix is totally NOT normative, it's just vibes and examples to help you picture the encoding 🙈
Our first example is an MRT record of type BGP4MP with subtype BGP4MP_MESSAGE_AS4. The Peer AS and Local AS numbers get 4-byte fields because of that subtype 💖 The BGP Update is shown in hex, and the AS numbers in its ASPATH are also 4-byte values, matching the BGP4MP_MESSAGE_AS4 subtype 🦋
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp = 1300475700 epoch sec (2011-03-18 19:15:00) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 16 | Subtype = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length = 82 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS = 64496 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local AS = 64497 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index = 0 | Address Family = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP Address = 192.0.2.85 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP Address = 198.51.100.4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Update =
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
00 3e 02 00 00 00 1f 40 01 01 02 40 02 0e 02 03
00 00 fb f0 00 00 fb ff 00 00 fb f6 40 03 04 c6
33 64 55 c0 08 04 fb f0 00 0e 18 cb 00 71
Figure 16: MRT BGP4MP_MESSAGE_AS4 ExampleHere's what the BGP Update Message in that figure says 👑
ORIGIN: INCOMPLETE
ASPATH: 64496 64511 64502
NEXT_HOP: 198.51.100.188
COMMUNITY: 64496:14
NLRI: 203.0.113.0/24
Figure 17: BGP Message ContentsNext up is an MRT record of type TABLE_DUMP_V2 with subtype PEER_INDEX_TABLE. This table holds 2 entries ✨
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp = 1300475700 epoch sec (2011-03-18 19:15:00) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 13 | Subtype = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length = 34 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Collector BGP ID = 198.51.100.4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| View Name Length = 0 | Peer Count = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Type = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer BGP ID = 198.51.100.5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP Address = 198.51.100.5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS = 65541 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Type = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer BGP ID = 192.0.2.33 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP Address = 192.0.2.33 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS = 65542 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: MRT PEER_INDEX_TABLE ExampleAnd last but not least, an MRT record of type TABLE_DUMP_V2 with subtype RIB_IPV6_UNICAST 🌈 This entry is for the NLRI prefix 2001:0DB8::/32. There's a single entry for that prefix, and it applies to the peer at index location 15 in an earlier MRT PEER_INDEX_TABLE record 🧚
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp = 1300475700 epoch sec (2011-03-18 19:15:00) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 13 | Subtype = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length = 87 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number = 42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preflen = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix = 2001:0DB8::/32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Entry Count = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Index = 15 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Originated Time = 1300475700 epoch sec (2011-03-18 19:15:00) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length = 68 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Path Attributes =
40 01 01 00 50 02 00 0e 02 03 00 00 fb f0 00 00
fb ff 00 00 fb f6 80 0e 2b 00 02 01 20 20 01 0d
b8 00 0d 00 ff 00 00 00 00 00 00 01 87 fe 80 00
00 00 00 00 00 02 12 f2 ff fe 9f 1b 00 00 00 20
20 01 0d b8
Figure 19: MRT RIB_IPV6_UNICAST ExampleHere's what those BGP Path Attributes add up to 💅
ORIGIN: IGP
ASPATH: 64496 64511 64502
MP_REACH_NLRI(IPv6 Unicast)
NEXT_HOP: 2001:db8:d:ff::187
NEXT_HOP: fe80::212:f2ff:fe9f:1b00
NLRI: 2001:0DB8::/32
Figure 20: BGP Path Attribute ContentsAppendix B. Deprecated MRT Types 🦋
this appendix is the throwback section 🕰️ it lists MRT types that are deprecated, and they're only here for informational purposes, so no one's using them anymore 💀
B.1. Deprecated MRT Informational Types 🍓
the original MRT format came with five Informational Type records 🌸 they were meant to signal the state of an MRT data collector, and they don't carry any routing info. They were built for when MRT records got sent over a network to a remote repository store. But repository stores have usually lived on the same device as the collector, so nobody's known to have actually implemented these Informational Types. Also, transport mechanisms for MRT records are considered outside the scope of this document 🫶
The Message field MAY contain an OPTIONAL string for diagnostic purposes 🔍 The message string encoding MUST follow the UTF-8 transformation format [RFC3629]. For these Types the Subtype field is unused, and it SHOULD be set to 0 💜
The MRT Informational Types are defined below 🌈
0 NULL
1 START
2 DIE
3 I_AM_DEAD
4 PEER_DOWNB.1.1. NULL Type ✨
the NULL Type message causes no operation. Literally nothing happens, and that's the whole point 😌
B.1.2. START Type 🚀
the START Type says a collector is about to start generating MRT records.
B.1.3. DIE Type 💀
the DIE Type tells a remote MRT repository that it SHOULD stop accepting messages 🙅♀️
B.1.4. I_AM_DEAD Type 🪦
an I_AM_DEAD MRT record means a collector has shut down and stopped generating MRT records. RIP.
B.1.5. PEER_DOWN Type 🙃
the PEER_DOWN message was meant to say a collector had lost its association with a BGP peer. But the MRT format already has BGP state change message types that do the same job, so this one kinda got replaced 💅
B.2. Other Deprecated MRT Types 👑
and these are the other deprecated MRT types, bestie 🎀
5 BGP
6 RIP
7 IDRP
8 RIPNG
9 BGP4PLUS
10 BGP4PLUS_01B.2.1. BGP Type
okay so the BGP Type is literally the one that says "this Message field has BGP routing info in it" 💅 🌸 the BGP routing protocol itself is defined in RFC 4271 [RFC4271]. what's inside depends on the Subtype value, and the BGP Type plus all of its Subtypes are considered deprecated now because the BGP4MP Type replaced them 🥀
the BGP Subtypes defined for the MRT BGP Type are below. same deal as the main type, they're ALL deprecated 💀
0 BGP_NULL
1 BGP_UPDATE
2 BGP_PREF_UPDATE
3 BGP_STATE_CHANGE
4 BGP_SYNC
5 BGP_OPEN
6 BGP_NOTIFY
7 BGP_KEEPALIVEB.2.1.1. BGP_NULL Subtype
the BGP_NULL Subtype is reserved. that's it, that's the whole tea ☕ 🫖
B.2.1.2. BGP_UPDATE Subtype
the BGP_UPDATE Subtype is used to encode BGP UPDATE messages 🎀 the MRT Message field for this subtype looks 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP UPDATE Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: BGP_UPDATE Subtypethe BGP UPDATE Contents hold the entire BGP UPDATE message, which comes right after the BGP Message Header. the header itself is NOT included, so don't go looking for it 🙈 the Peer AS Number and Peer IP Address fields tell you the AS number and IP address of the remote system that's generating the BGP UPDATE messages. the Local AS Number and Local IP Address fields hold the AS number and IP address of the local collector system that's archiving the messages. the collector is the main character here 🦋
B.2.1.3. BGP_PREF_UPDATE Subtype
the BGP_PREF_UPDATE Subtype is not defined. nothing to see here, moving on 🫠
B.2.1.4. BGP_STATE_CHANGE Subtype
the BGP_STATE_CHANGE Subtype is used to reflect changes in the BGP finite state machine 🔥 those FSM states are defined in RFC 4271 [RFC4271], Section 8.2.2. both the Old State value and the New State value are encoded as 2-octet numbers. the state values are defined numerically like this:
1 Idle
2 Connect
3 Active
4 OpenSent
5 OpenConfirm
6 Establishedthe format of the BGP_STATE_CHANGE Subtype MRT Message field is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old State | New State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: BGP_STATE_CHANGE SubtypeB.2.1.5. BGP_SYNC Subtype
okay this one is a little bit of a ghost 👻 the BGP_SYNC Subtype was meant to carry a system file name where BGP Table Dump messages MAY be recorded. the View Number was supposed to match the View Number from the TABLE_DUMP Type records. there are NO known implementations of this subtype, and it SHOULD be ignored 🙃 the format for it looks 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| View Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| File Name... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: BGP_SYNC Subtypethe File Name is terminated with a NULL (0) character 🧁
B.2.1.6. BGP_OPEN Subtype
the BGP_OPEN Subtype is used to encode BGP OPEN messages 💜 the MRT Message field has the same format as the BGP_UPDATE, except the last field contains the contents of the BGP OPEN message. same bones, different vibes ✨
B.2.1.7. BGP_NOTIFY Subtype
the BGP_NOTIFY Subtype is used to encode BGP NOTIFICATION messages 🚨 the format is the same as the BGP_UPDATE, except the last field contains the contents of the BGP NOTIFICATION message.
B.2.1.8. BGP_KEEPALIVE Subtype
the BGP_KEEPALIVE Subtype is used to encode BGP KEEPALIVE messages 🫶 the format is the same as the BGP_UPDATE, except the last field contains NO information. just vibes, literally 🌈
B.2.2. RIP Type
the RIP Type is used to export RIP packets as defined in RFC 2453 [RFC2453] 🍓 the Subtype field is currently reserved for this type and SHOULD be set to 0. the MRT Message field for the RIP Type looks 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RIP Message Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: RIP TypeB.2.3. IDRP Type
the IDRP Type was meant to export Inter-Domain Routing Protocol (IDRP) info as defined in the ISO/IEC 10747 standard. however, this type has seen NO known use, and there are no details on protocol encoding for it. it's giving ghost town 👻
B.2.4. RIPNG Type
the RIPNG Type is used to export RIPNG protocol packets as defined in RFC 2080 [RFC2080] 🧚 RIPNG basically updates RIP so it works with IPv6 🌸 the Subtype field is currently reserved for this type and SHOULD be set to 0. the MRT Message field for the RIPNG Type looks 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Peer IPv6 Address ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Local IPv6 Address ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RIPNG Message Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: RIPNG TypeB.2.5. BGP4PLUS and BGP4PLUS_01 Types
the BGP4PLUS and BGP4PLUS_01 Types were defined to support IPv6 BGP routing info 🌍 the BGP4PLUS Type was based on the initial Internet-Draft that became RFC 4760, "Multiprotocol Extensions to BGP-4". the BGP4PLUS_01 Type was specified to match the -01 revision of that Internet-Draft. the two Types share the SAME definitions in terms of their MRT format specifications, so they're basically twins 👯
the Subtype field definitions are shared with the BGP Type, BUT the address fields in the BGP_UPDATE, BGP_OPEN, BGP_NOTIFY, BGP_KEEPALIVE, and BGP_STATE_CHANGE Subtype records are extended to 16 octets for IPv6 addresses 📏 as with the BGP Type, the BGP4PLUS and BGP4PLUS_01 Types are deprecated, since they were superseded by the BGP4MP Type. bye bye 👋
B.2.6. Deprecated BGP4MP Subtypes
the following two subtypes of the BGP4MP Type are considered deprecated 🥀
2 BGP4MP_ENTRY
3 BGP4MP_SNAPSHOTB.2.6.1. BGP4MP_ENTRY Subtype
this subtype is similar to the TABLE_DUMP Type and is used to record RIB table entries 📚 it was intended to include true multiprotocol support, BUT it doesn't support 4-byte AS numbers and it never really got widely implemented. oof 😭
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS Number | Local AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP Address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP Address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| View Number | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Last Change |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | SAFI | Next-Hop-Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop Address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Attribute... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26: BGP4MP_ENTRY SubtypeB.2.6.2. BGP4MP_SNAPSHOT Subtype
this subtype was meant to carry a system file name where BGP4MP_ENTRY records MAY be recorded 🗂️ it's basically a cousin of the BGP_SYNC Subtype, and it's deprecated too.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| View Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| File Name... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 27: BGP4MP_SNAPSHOT SubtypeAppendix C. Acknowledgements 🎀
the initial MRT specification was developed by Craig Labovitz for use in the Multi-thread Routing Toolkit (MRT) project 🙌 the BGP4MP Type was introduced in the Zebra routing software project by Kunihiro Ishiguro 🦋 and the BGP4MP_ET, ISIS, and ISIS_ET Types were defined in the Python Routing Toolkit (PyRT) developed by Richard Mortier while at Sprint Advanced Technology Labs 👑
Authors' Addresses ✨
Okay bestie, here are the people who wrote this one and how to reach them 💌
Larry Blunk 🎀
- Merit Network
- EMail:
ljb@merit.edu
Manish Karir 🦋
- Merit Network
- EMail:
mkarir@merit.edu
Craig Labovitz 🌸
- Deepfield Networks
- EMail:
labovit@deepfield.net
🫶 Three legends, one MRT spec. Slay forever 👑
📦 where this page comes from
- ietf: rfc6396 2011-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms