The following errata report has been held for document update 
for RFC7854, "BGP Monitoring Protocol (BMP)". 

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7133

--------------------------------------
Status: Held for Document Update
Type: Technical

Reported by: John Scudder <[email protected]>
Date Reported: 2022-09-14
Held by: Mohamed Boucadair (IESG)

Section: 5

Original Text
-------------
   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.


Corrected Text
--------------
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/

===Verifier notes

See also https://mailarchive.ietf.org/arch/msg/grow/7ZFA52R3KI9pgpAN302xLl9MBBA/

--------------------------------------
RFC7854 (draft-ietf-grow-bmp-17)
--------------------------------------
Title               : BGP Monitoring Protocol (BMP)
Publication Date    : June 2016
Author(s)           : J. Scudder, Ed., R. Fernando, S. Stuart
Category            : PROPOSED STANDARD
Source              : Global Routing Operations
Stream              : IETF
Verifying Party     : IESG

_______________________________________________
GROW mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to