RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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

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

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

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

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

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

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

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

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

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.

Report New Errata