RFC Errata
Found 17 records.
Status: Verified (9)
RFC 7868, "Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP)", May 2016
Source of RFC: INDEPENDENT
Errata ID: 5030
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Travis P. Bonfigli
Date Reported: 2017-06-06
Verifier Name: Nevil Brownlee
Date Verified: 2017-07-20
Section 6.7.4 says:
6.7.4. 0x0004 - SOFTWARE_VERSION_TYPE Field Length Vender OS major version 1 Vender OS minor version 1 EIGRP major revision 1 EIGRP minor revision 1 The EIGRP TLV Version fields are used to determine TLV format versions. Routers using Version 1.2 TLVs do not understand Version 2.0 TLVs, therefore Version 2.0 routers must send the packet with both TLV formats in a mixed network. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x0004 | 0x000C | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Vendor Major V.|Vendor Minor V.| EIGRP Major V.| EIGRP Minor V.| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It should say:
6.7.4. 0x0004 - SOFTWARE_VERSION_TYPE Field Length Vender OS major version 1 Vender OS minor version 1 EIGRP major revision 1 EIGRP minor revision 1 The EIGRP TLV Version fields are used to determine TLV format versions. Routers using Version 1.2 TLVs do not understand Version 2.0 TLVs, therefore Version 2.0 routers must send the packet with both TLV formats in a mixed network. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x0004 | 0x0008 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Vendor Major V.|Vendor Minor V.| EIGRP Major V.| EIGRP Minor V.| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notes:
Hello! In looking over the TLV construct in Section 6.7.4 0x0004 - SOFTWARE_VERSION_TYPE it appears that they might be a 'typo' with respect to the 'Length' value provided in the RFC diagram. The current value is shown as 0x000C (12 bytes), but in reality it appears that it should be 0x0008 (8 bytes) given the format/length of the specific TLV being discussed. Thank you.
Cheers,
Travis
Errata ID: 5952
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christopher Hart
Date Reported: 2019-12-30
Verifier Name: Adrian Farrel
Date Verified: 2020-01-19
Section 6.5 says:
RS-Flag (0x04): The Restart flag is set in the HELLO and the UPDATE packets during the restart period. The router looks at the RS- Flag to detect if a neighbor is restarting. From the restarting routers perspective, if a neighboring router detects the RS-Flag set, it will maintain the adjacency, and will set the RS-Flag in its UPDATE packet to indicated it is doing a soft restart.
It should say:
RS-Flag (0x04): The Restart flag is set in the HELLO and the UPDATE packets during the restart period. A router looks at the RS- Flag to detect if a neighbor is restarting. From the restarting router's perspective, if a neighboring router detects the RS- Flag is set, the neighboring router will maintain the adjacency with the restarting router. The restarting router will set the RS-Flag in its UPDATE packet to indicate it is performing a soft restart.
Notes:
Cleaning up the grammar for the RS-Flag portion of Section 6.5. The grammar used in the original text can be ambiguously interpreted as to whether the restarting router initially sets the RS-Flag in its Update packet, or the neighboring router initially sets the RS-Flag in its Update packet.
Errata ID: 6086
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Rafał Cygnarowski
Date Reported: 2020-04-11
Verifier Name: RFC Editor
Date Verified: 2020-04-21
Section 5.4.2. says:
Routes learned though interfaces that EIGRP is NOT using to reach the destination may have the route advertised out those interfaces.
It should say:
Routes learned through interfaces that EIGRP is NOT using to reach the destination may have the route advertised out those interfaces.
Notes:
Typo in 'through' word.
Errata ID: 6092
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Rafał Cygnarowski
Date Reported: 2020-04-12
Verifier Name: Adrian Farrel
Date Verified: 2020-04-22
Section 6.7.7. says:
0x0007 - PEER_ TERMINATION_TYPE
It should say:
0x0007 - PEER_TERMINATION_TYPE
Notes:
Removed extra space in section title.
Errata ID: 6318
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stanislav Asanov
Date Reported: 2020-10-24
Verifier Name: Adrian Farrel
Date Verified: 2020-10-24
Section 6.6.1 says:
Type Low: 1 octet that defines the TLV Opcode; see TLV Definitions in Section 3.
It should say:
Type Low: 1 octet that defines the TLV Opcode; see TLV Definitions in Sections 6.7, 6.8, and 6.9.
Notes:
There are no TLV definitions in Section 3. The TLV Opcodes are defined in Sections 6.7, 6.8, 6.9.
Errata ID: 6320
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stanislav Asanov
Date Reported: 2020-10-26
Verifier Name: Adrian Farrel
Date Verified: 2020-10-27
Section 6.9.3.8.1 says:
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x07 | Offset | Next-Hop Addr. (Upper 2 bytes)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address (Lower 2 bytes) | RID (Upper 2 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RID (Upper 2 bytes) | Admin Tag (Upper 2 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Admin Tag (Upper 2 bytes) |Extern Protocol| Flags Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It should say:
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x07 | Offset | Next-Hop Addr. (Upper 2 bytes)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next-Hop Addr. (Lower 2 bytes)| RID (Upper 2 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RID (Lower 2 bytes) | Admin Tag (Upper 2 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Admin Tag (Lower 2 bytes) |Extern Protocol| Flags Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notes:
1. There is no subfield named "IPv4 Address" in AddPath field. The label in the 5th and 6th octets of the AddPath field is a typo, and it should read "Next-Hop Addr. (Lower 2 bytes)".
2. The subfield "RID (Upper 2 bytes)" is repeated in the AddPath field, and there is no subfield for lower 2 bytes of RID. The same with "Admin Tag (Upper 2 bytes)" subfield.
Errata ID: 6322
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stanislav Asanov
Date Reported: 2020-10-27
Verifier Name: Adrian Farrel
Date Verified: 2020-10-29
Section 6.9.3.8.2. says:
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x07 | Offset | Next-Hop Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | (16 octets) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | | RID (Upper 2 byes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RID (Upper 2 byes) | Admin Tag (Upper 2 byes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Admin Tag (Upper 2 byes) | Extern Protocol | Flags Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It should say:
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x07 | Offset | Next-Hop Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | (16 octets) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | | RID (Upper 2 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RID (Lower 2 bytes) | Admin Tag (Upper 2 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Admin Tag (Lower 2 bytes) | Extern Protocol | Flags Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notes:
The subfield "RID (Upper 2 bytes)" is repeated in the AddPath with IPv6 Next Hop field, and there is no subfield for lower 2 bytes of RID. The same with "Admin Tag (Upper 2 bytes)" subfield. Typo in the word "bytes".
Errata ID: 6852
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eren Elçin
Date Reported: 2022-02-15
Verifier Name: RFC Editor
Section 6.8.6.3 says:
This TLV is used to provide community tags for specific IPv4 destinations.
It should say:
This TLV is used to provide community tags for specific IPv6 destinations.
Notes:
It is under the IPv6 section of the RFC. IPv4 and IPv6 sections are really similiar and consecutively written, so its highly probable that after copy pasting the common information for both IPv4 and IPv6 to each other, forget to change that part from IPv4 to IPv6.
Errata ID: 6853
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eren Elçin
Date Reported: 2022-02-16
Verifier Name: RFC Editor
Date Verified: 2022-04-06
Section 6.9.3.8.1. says:
Next-Hop Address: An IPv4 address represented by four 8-bit values (total 4 octets). If the value is zero (0), the IPv6 address from the received IPv4 header is used as the next hop for the route. Otherwise, the specified IPv4 address will be used.
It should say:
Next-Hop Address: An IPv4 address represented by four 8-bit values (total 4 octets). If the value is zero (0), the IPv4 address from the received IPv4 header is used as the next hop for the route. Otherwise, the specified IPv4 address will be used.
Notes:
The address format in this Packet format at this section of the RFC is made for IPv4 type addresses. So, "IPv6 address from the received IPv4 header" should be "IPv4 address from the received IPv4 header".
Status: Reported (5)
RFC 7868, "Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP)", May 2016
Source of RFC: INDEPENDENT
Errata ID: 5242
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Innokentiy Solntsev
Date Reported: 2018-01-24
Edited by: Adrian Farrel
Date Edited: 2020-04-22
Section 5.6.2.5 says:
K5 metric =[(K1*Net-Throughput) + Latency)+(K6*ExtAttr)] * ------ K4+Rel
It should say:
K5 metric =[Net-Throughput+Latency+(K6*ExtAttr)] * ------ K4+Rel
Notes:
1. Round brackets aren't balanced.
2. There shouldn't be K1, as Net-Throughput already includes it.
Errata ID: 5691
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Gabriel Torres
Date Reported: 2019-04-14
Section 5.6.1.1 says:
The calculated EIGRP bandwidth (BW) metric is then: 256 * (10^7)/BW = 256 * {(10^7)/10,000} = 256 * 1000 = 256,000 And the calculated EIGRP delay metric is then: 256 * sum of delay = 256 * 100 * 10 microseconds = 25,600 (in tens of microseconds)
It should say:
The calculated EIGRP bandwidth (BW) metric is then: (10^7)/BW = {(10^7)/10,000} = 1,000 And the calculated EIGRP delay metric is then: sum of delay = 1 ms = 100 tens of microseconds Thus the composite metric is: 256 * 1000 * 100 = 25,600,000
Notes:
The 256 should be multiplied by the sum of the bandwidth and the delay, and not multiplied by each individual parameter.
1 ms = 1,000 microseconds = 100 tens of microseconds
Errata ID: 6084
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Rafał Cygnarowski
Date Reported: 2020-04-10
Section 5.6.2.3. says:
The formula for the conversion for Max-Throughput value directly from the interface without consideration of congestion-based effects is as follows: (EIGRP_BANDWIDTH * EIGRP_WIDE_SCALE) Max-Throughput = K1 * ------------------------------------ Interface Bandwidth (kbps) If K2 is used, the effect of congestion as a measure of load reported by the interface will be used to simulate the "available Throughput" by adjusting the maximum Throughput according to the formula: K2 * Max-Throughput Net-Throughput = Max-Throughput + --------------------- 256 - Load
It should say:
The formula for the conversion for Max-Throughput value directly from the interface without consideration of congestion-based effects is as follows: EIGRP_BANDWIDTH * EIGRP_WIDE_SCALE Max-Throughput = ------------------------------------ Interface Bandwidth (kbps) If K2 is used, the effect of congestion as a measure of load reported by the interface will be used to simulate the "available Throughput" by adjusting the maximum Throughput according to the formula: K2 * Max-Throughput Net-Throughput = K1 * Max-Throughput + --------------------- 256 - Load
Notes:
K1 can't be a part of Max-Throughput as it affects Net-Throughput twice. Moreover: in case of K1=0, K2 become ignored as it will be multiplied by 0.
Together with errata ID: 5242 which fixes metric formula {metric =[Net-Throughput+Latency+(K6*ExtAttr)] * K5/(K4+Rel) }, results become correct and are same as on live equipment.
Errata ID: 6088
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Rafał Cygnarowski
Date Reported: 2020-04-12
Section 6.1. says:
EIGRP IPv4 will transmit HELLO packets using either the unicast destination of a neighbor or using a multicast host group address [7] with a source address EIGRP IPv4 multicast address [13].
It should say:
EIGRP IPv4 will transmit HELLO packets using either the unicast destination of a neighbor or using a multicast host group address [7] with a destination address EIGRP IPv4 multicast address [13].
Notes:
Multicast address is a destination address.
Errata ID: 6090
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Rafał Cygnarowski
Date Reported: 2020-04-12
Section 5.6.2.5. says:
metric = (K1 * min(Throughput)) + (K3 * sum(Latency)) }
It should say:
metric = K1 * Max-Throughput + Latency
Notes:
This errata is consequence of:
- erratas 5242 and 6084,
- inconsistency of using (Max-)Throughput and Latency variables,
- using additional min() and sum() functions which are not used in formula where all K-values takes effect ( metric =[Net-Throughput+Latency+(K6*ExtAttr)] * K5/(K4+Rel)) .
The Max-Throughput variable defined in 5.6.2.3. is a little bit unfortunate, as in fact it is minimum of maximum available throughput of all network segments in the path.
I removed also K3 value from the metric as it is already embraced in Latency calculation in 5.6.2.4.
I decided to use this formula as it is mathematically correct and is least intrusive but the best would be to review notations from 5.6.2.3. up to .5 and remove all inaccuracies. Also highlighting usage of K-Values in final metric calculation would make this document more readable, eg. metric = K1 * Throughtput + K3 * Latency - which shows best how K-values affect metric.
Status: Held for Document Update (3)
RFC 7868, "Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP)", May 2016
Source of RFC: INDEPENDENT
Errata ID: 5185
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Varadhan Venkataseshan
Date Reported: 2017-11-21
Held for Document Update by: Adrian Farrel
Date Held: 2018-04-08
Section 6.9.3.5 says:
across a network measured in measured in microseconds.
It should say:
across a network measured in microseconds.
Notes:
Words "measured in" is repeated twice at line number 3965 in section 6.9.3.5
Errata ID: 6089
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Rafał Cygnarowski
Date Reported: 2020-04-12
Held for Document Update by: Adrian Farrel
Date Held: 2020-04-22
Section 5.5.2 says:
EIGRP uses one-way- based values either provided by the interface or computed as a factor of the link s bandwidth.
It should say:
EIGRP uses one-way- based values either provided by the interface or computed as a factor of the link's bandwidth.
Notes:
Missing apostrophe (') in "link's".
Errata ID: 6091
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Rafał Cygnarowski
Date Reported: 2020-04-12
Held for Document Update by: Adrian Farrel
Date Held: 2020-04-22
Section 6.7.4. says:
Vender OS major version 1 Vender OS minor version 1
It should say:
Vendor OS major version 1 Vendor OS minor version 1
Notes:
Typo in 'Vendor' word.