RFC Errata
Found 9 records.
Status: Held for Document Update (7)
RFC 4274, "BGP-4 Protocol Analysis", January 2006
Source of RFC: idr (rtg)
Errata ID: 3777
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Held for Document Update by: Stewart Bryant
Date Held: 2013-10-30
(5) like (4)
Section 6.1.2, on page 8, exhibits similar symptoms as noted above.
The RFC says:
To quantify the worst-case memory requirements for BGP, we denote the
total number of networks in the Internet as N, the mean AS distance
of the Internet as M (distance at the level of an autonomous system,
expressed in terms of the number of autonomous systems), the total
number of unique AS paths as A. Then the worst-case memory
requirements (MR) can be expressed as
MR = O(N + (M * A))
Because a mean AS distance M is a slow moving function of the
interconnectivity ("meshiness") of the Internet, for all practical
purposes the worst-case router memory requirements are on the order
| of the total number of networks in the Internet multiplied by the
| number of peers that the local system is peering with. [...]
Apparently, the first part of that text has been revised eliminating
the role of the peering count. Thus the last sentence should have
been updated accordingly, to make it match the new formula.
The second paragraph thus perhaps should say:
Because a mean AS distance M is a slow moving function of the
interconnectivity ("meshiness") of the Internet, for all practical
purposes the worst-case router memory requirements are on the order
| of the total number of networks in the Internet. [...]
Notes:
from errata 148
Rather than follow this suggestion (and drop the number of peers term out of the prose) it may be more would be more accurate to insert a number of peers term into the formula, e.g. MR = O(P * (N + (M * A))), where P is the number of peers.
This does not impact interoperability and thus should be looked at in any future update of the RFC.
Errata ID: 3776
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Held for Document Update by: Stewart Bryant
Date Held: 2013-10-30
(4) inconsistency in updated text
The text of section 6.1 has been revised substantially from its
predecessor, RFC 1774. Unfortunately, the modifications have
not been performed incompletely, leading to near-nonsense text.
Section 6.1, on page 7, says:
Immediately after the initial BGP connection setup, BGP peers
exchange complete sets of routing information. If we denote the
total number of routes in the Internet as N, the total path
attributes (for all N routes) received from a peer as A, and assume
that the networks are uniformly distributed among the autonomous
systems, then the worst-case amount of bandwidth consumed during the
| initial exchange between a pair of BGP speakers (P) is
| BW = O((N + A) * P)
^^^^ ^^^^^
This makes no sense -- obviously you can't multiply by a non-numeric
quantity P, "a pair of BGP speakers".
I strongly suspect that it was the intention to say:
Immediately after the initial BGP connection setup, BGP peers
exchange complete sets of routing information. If we denote the
total number of routes in the Internet as N, the total path
attributes (for all N routes) received from a peer as A, and assume
that the networks are uniformly distributed among the autonomous
systems, then the worst-case amount of bandwidth consumed during the
| initial exchange between a pair of BGP speakers is
| BW = O((N + A))
Please verify.
Notes:
from errata 148
This has no impact on interoperability. It should be looked at on any update of the RFC.
Errata ID: 148
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Held for Document Update by: Stewart Bryant
Date Held: 2013-10-30
The final paragraph on page 8,
The following table illustrates typical memory requirements of a
router running BGP. We denote the average number of routes
advertised by each peer as N, the total number of unique AS paths as
A, the mean AS distance of the Internet as M (distance at the level
of an autonomous system, expressed in terms of the number of
autonomous systems), the number of octets required to store a network
as R, and the number of bytes required to store one AS in an AS path
| as P. It is assumed that each network is encoded as four bytes, each
AS is encoded as two bytes, and each networks is reachable via some
| fraction of all the peers (# BGP peers/per net). For purposes of the
| estimates here, we will calculate MR = (((N * R) + (M * A) * P) * S).
^^^^ ^^^^
and the table on page 9,
vvvvvvvvvvvvvvvvvvv
| # Networks Mean AS Distance # ASes # BGP peers/per net Memory Req
| (N) (M) (A) (P) (MR)
---------- ---------------- ------ ------------------- -------------
100,000 20 3,000 20 10,400,000
100,000 20 15,000 20 20,000,000
120,000 10 15,000 100 78,000,000
140,000 15 20,000 100 116,000,000
exhibit additional issues:
- The text defines 'P' as
"the number of bytes required to store one AS in an AS path"
while apparently in the table (P) means
"# BGP peers/per net".
- 'S' in the formula in the last line of page 9 is not defined
anywhere in the text.
- "# BGP peers/per net" IMHO does not even make sense in the
context of BGP, since BGP speakers represent ASes, not networks
(prefixes).
I do not have a proposal for an easy way to get rid of these
inconsistencies.
Please check.
Notes:
There is clearly a problem with the text, but it does not impact interoperability and should be looked at when the RFC is revised.
Errata ID: 3774
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Held for Document Update by: Stewart Bryant
Date Held: 2013-10-30
(6) typos / grammar
In Section 10, the second paragraph on page 13 says:
| BGP uses TCP MD5 option for validating data and protecting against
spoofing of TCP segments exchanged between its sessions. The usage
of TCP MD5 option for BGP is described at length in [RFC2385]. The
TCP MD5 Key management is discussed in [RFC3562]. BGP data
| encryption is provided using the IPsec mechanism, which encrypts the
| IP payload data (including TCP and BGP data). The IPsec mechanism
| can be used in both the transport mode and the tunnel mode. The
| IPsec mechanism is described in [RFC2406]. Both the TCP MD5 option
| and the IPsec mechanism are not widely deployed security mechanisms
for BGP in today's Internet. Hence, it is difficult to gauge their
| real performance impact when using with BGP. However, because both
| the mechanisms are TCP- and IP-based security mechanisms, the Link
Bandwidth, CPU utilization and router memory consumed by BGP would be
| the same as any other TCP- and IP-based protocols.
It should say, correcting grammar and unclear semantics:
| BGP uses the TCP MD5 option for validating data and protecting
against spoofing of TCP segments exchanged between its sessions. The
usage of TCP MD5 option for BGP is described at length in [RFC2385].
The TCP MD5 Key management is discussed in [RFC3562]. BGP data
| encryption is provided using the IPsec ESP mechanism, which encrypts
| the IP payload data (including TCP and BGP data). The IPsec ESP
| mechanism can be used in both transport mode and tunnel mode. The
| IPsec ESP mechanism is described in [RFC2406]. Both the TCP MD5
| option and IPsec ESP are not widely deployed security mechanisms
for BGP in today's Internet. Hence, it is difficult to gauge their
| real performance impact when used with BGP. However, because both
| mechanisms are TCP- and IP-based security mechanisms, the Link
Bandwidth, CPU utilization and router memory consumed by BGP would be
the same as any for other TCP- and IP-based protocols.
(I am in doubt whether the last sentence is appropriate;
at least, "the same as" should better be replaced by "similar as".
Preferrably, I would delete that sentence.)
Finally, the 4th paragraph on page 13,
v
| Such flexible TCP- and IP-based security mechanisms, allow BGP to
prevent insertion/deletion/modification of BGP data, any snooping of
the data, session stealing, etc. [...]
should say:
| Such flexible TCP- and IP-based security mechanisms allow BGP to
prevent insertion/deletion/modification of BGP data, any snooping of
the data, session stealing, etc. [...]
Notes:
from errata 148
Errata ID: 3773
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Held for Document Update by: Stewart Bryant
Date Held: 2013-10-30
(3) typos (multiple missing articles) Section 4 of RFC 4274, on page 6, says: Whenever a BGP speaker detects an error in a peer connection, it shuts down the peer and changes its FSM state to IDLE. BGP speaker requires a Start event to re-initiate an idle peer connection. If the error remains persistent and BGP speaker generates a Start event automatically, then it may result in persistent peer flapping. Although peer oscillation is found to be wide-spread in BGP implementations, methods for preventing persistent peer oscillations are outside the scope of base BGP specification.
It should say:
It should say: Whenever a BGP speaker detects an error in a peer connection, it | shuts down the peer and changes its FSM state to IDLE. A BGP speaker requires a Start event to re-initiate an idle peer connection. If | the error remains persistent and the BGP speaker generates a Start event automatically, then it may result in persistent peer flapping. Although peer oscillation is found to be wide-spread in BGP implementations, methods for preventing persistent peer oscillations | are outside the scope of the base BGP specification.
Notes:
from errata 148
Errata ID: 3772
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Held for Document Update by: Stewart Bryant
Date Held: 2013-10-30
(2) typo Section 2.3 contains (on page 5) the state description: ACTIVE: State in which BGP peer is trying to acquire a peer | by listening and accepting TCP connection.
It should say:
ACTIVE: State in which BGP peer is trying to acquire a peer
| by listening and accepting a TCP connection.
^^^
(An alternative correction, replacing 'connection' by 'connections',
does not precisely reflect the desired behaviour.)
Notes:
from errata 148
Errata ID: 3771
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Held for Document Update by: Stewart Bryant
Date Held: 2013-10-30
(1) typo (missing word) The second paragraph of Section 2.2, on page 4 of RFC 4274, says: BGP uses an incremental update strategy to conserve bandwidth and | processing power. That is, after initial exchange of complete routing information, a pair of BGP routers exchanges only the changes to that information. [...]
It should say:
It should say: BGP uses an incremental update strategy to conserve bandwidth and | processing power. That is, after the initial exchange of complete routing information, a pair of BGP routers exchanges only the changes to that information. [...]
Status: Rejected (2)
RFC 4274, "BGP-4 Protocol Analysis", January 2006
Source of RFC: idr (rtg)
Errata ID: 3775
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Rejected by: Stewart Bryant
Date Rejected: 2013-10-30
(7) some Ref's inappropriately named Normative The References "[BGP-VULN]" and "[SBGP]" do not fulfill the criteria for being used as Normative References. Their inclusion in Section 11.1, on page 14, might formally be seen as inhibiting the progress of BGP-4 on the Standards Track.
Notes:
This was considered OK by the IETF and IESG of the time.
--VERIFIER NOTES--
The status of these references will have been considered by the IETF and the IESG of the time. The authors and reviewers of any future BGP document will evaluate the correct status of the references that they use.
Errata ID: 3803
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ramakrishna DTV
Date Reported: 2013-11-14
Rejected by: Stewart Bryant
Date Rejected: 2014-03-02
Section 2.1 says:
BGP enhances the AS_PATH attribute to include sets of autonomous systems as well as lists via the AS_SET attribute.
It should say:
BGP enhances the AS_PATH attribute to include sets of autonomous systems as well as lists via the AS_SET path segment type.
Notes:
AS_SET is not an attribute. It is a path segment type.
--VERIFIER NOTES--
BCP: 172 recommends for Not Using AS_SET and AS_CONFED_SET in BGP, and thus this is unlikely to be an issue in the long term.