RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 5 records.

Status: Verified (2)

RFC 7854, "BGP Monitoring Protocol (BMP)", June 2016

Source of RFC: grow (ops)

Errata ID: 7194
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Ahmed Elhassany
Date Reported: 2022-10-30
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2022-11-03

Section 10.8 says:

   Information type values 0 through 32767 MUST be assigned using the
   "Standards Action" policy, and values 32768 through 65530 using the
   "Specification Required" policy, defined in [RFC5226].  Values 65531
   through 65534 are Experimental, and values 0 and 65535 are Reserved.

It should say:

   Information type values 0 through 127 MUST be assigned using the
   "Standards Action" policy, and values 128 through 250 using the
   "Specification Required" policy, defined in [RFC5226].  Values 251
   through 254 are Experimental, and values 0 and 255 are Reserved.

Notes:

In Section 4.9 Peer Down Notification. The "Reason" field is defined as one octet, while the IANA consideration section is defining values as 2-octets range. This errata suggests updating the IANA registry, instead of the size of the "Reason" field in the Peer Down Notification message to avoid breaking existing implementations that use one-octet reason.

[WK]: See thread https://mailarchive.ietf.org/arch/msg/grow/s-qcQpAkFVK3beirNYqY4MYfbFw/ for tracking. IANA has confirmed that they can update registries from verified errata.

Errata ID: 4722
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Stéphane Bortzmeyer
Date Reported: 2016-06-28
Verifier Name: Joel Jaeggli
Date Verified: 2017-03-29

Section 3.1 4.8 7 says:

Stats Reports

It should say:

Statistics Reports

Notes:

The message of type 1 is called "Statistics Report" in the IANA registry https://www.iana.org/assignments/bmp-parameters/bmp-parameters.xml#message-types (I used it as the reference) and in sections 4.1 and 10.1 but "Stats Report" in sections 3.1, 4.8 and 7.

Status: Reported (1)

RFC 7854, "BGP Monitoring Protocol (BMP)", June 2016

Source of RFC: grow (ops)

Errata ID: 7133
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: John Scudder
Date Reported: 2022-09-14

Section 5 says:

   In BMP's normal operating mode, after the BMP session is up, Route
   Monitoring messages are used to provide a snapshot of the Adj-RIB-In
   of each monitored peer.  This is done by sending all routes stored in
   the Adj-RIB-In of those peers using standard BGP Update messages,
   encapsulated in Route Monitoring messages.  There is no requirement
   on the ordering of messages in the peer dumps.  When the initial dump
   is completed for a given peer, this MUST be indicated by sending an
   End-of-RIB marker for that peer (as specified in Section 2 of
   [RFC4724], plus the BMP encapsulation header).  See also Section 9.

It should say:

Regrettably, there is no straightforward correction. Please see the notes for details.

Notes:

BMP is specified in the indicated text as sending "an End-of-RIB marker for that peer". The problem is that End-of-RIB (EoR) markers aren't specified in RFC 4724 as being per-peer, but per address family (AF), thus it doesn't make sense to talk about sending a single EoR to indicate BMP completion, except in the special case where BMP is only transporting routes for a single address family.

This problem also occurs in Section 3.3:

encapsulated in Route Monitoring messages. Once it has sent all the
routes for a given peer, it MUST send an End-of-RIB message for that
peer; when End-of-RIB has been sent for each monitored peer, the
initial table dump has completed. (A monitoring station that only
wants to gather a table dump could close the connection once it has
gathered an End-of-RIB or Peer Down message corresponding to each
Peer Up message.)

but the underlying fault is in Section 5, so that's what I've referenced above.

There are various fixes that could be applied. Some of them include:

1. Remove all references to EoR. Don't require that an EoR be sent in §5, don't talk about what to do with it in §3.3. I'm not very fond of this option, its only merit is that it's simple to specify the textual changes.

2. Update §5 to note that an EoR has to be sent per AF, and update §3.3 similarly, including in the parenthetical comment noting that the station would have to gather an EoR per AF that's supported on the session.

3. Introduce a new BMP message "end of initial BMP convergence" to provide the functionality. Probably this would be in addition to the fixes in #2, since it's still useful to know that a given AF dump has completed. But introduction of the new message would provide a simpler and probably more reliable way for the monitoring station to know that BMP-level synchronization had completed.

It seems to me that the best way to address this will be with either a new spec that updates RFC 7854, or an rfc7854bis. For this reason, I suggest this erratum should be verified as "hold for document update", since the solution requires more WG discussion and consensus than an erratum can provide.

This issue was first reported by Vincent Bernat in https://mailarchive.ietf.org/arch/msg/idr/FOEcdxtI03CdgDrn497NBFSpz-s/, and see also https://mailarchive.ietf.org/arch/msg/grow/o16w8s5Ba9J4MdIipbxIqDiZrCI/

Status: Held for Document Update (2)

RFC 7854, "BGP Monitoring Protocol (BMP)", June 2016

Source of RFC: grow (ops)

Errata ID: 4830
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Suhas Anand
Date Reported: 2016-10-12
Held for Document Update by: Joel Jaeggli
Date Held: 2017-03-29

Section 4.9 says:

Peer Down Notification

   This message is used to indicate that a peering session was
   terminated.

      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
     +-+-+-+-+-+-+-+-+
     |    Reason     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Data (present if Reason = 1, 2 or 3)               |
     ~                                                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

Peer Down Notification

   This message is used to indicate that a peering session was
   terminated. Following the common BMP header and per-peer header is 
   the following:

      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
     +-+-+-+-+-+-+-+-+
     |    Reason     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Data (present if Reason = 1, 2 or 3)               |
     ~                                                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

What:

For Peer Down Notification: To the programmer implementing the RFC, it is not clear if the Peer Down message consists of per peer header

Errata ID: 5736
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Mohamed Boucadair
Date Reported: 2019-05-23
Held for Document Update by: Warren Kumari (Ops AD)
Date Held: 2019-07-01

Section 4.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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Peer Type   |  Peer Flags   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Peer Distinguisher (present based on peer type)       |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 Peer Address (16 bytes)                       |
     ~                                                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Peer AS                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Peer BGP ID                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Timestamp (seconds)                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  Timestamp (microseconds)                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Peer Type   |  Peer Flags   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Peer Distinguisher (present based on peer type)       |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 Peer Address (16 bytes)                       |
     ~                                                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Peer AS                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Peer BGP ID                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Timestamp (seconds)                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  Timestamp (microseconds)                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

The OLD figure may be misinterpreted as if there are unused bits between the "Peer Flags" and "Peer Distinguisher".
WK: This also makes is consistent with other diagrams in this RFC.

Report New Errata



Advanced Search