(I moved idr to bcc, this is a grow doc, so let’s continue the conversation just on [email protected])
Hi All, I agree this is a bug. Thanks, Vincent, for pointing it out. I think it should be fixed. Unfortunately (well, from the point of view of fixing it with an erratum anyway), there are several possible fixes and none of them is obviously the right one. One fix would be to completely remove this text: 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.) That would eliminate any specified way to know that initial convergence had completed, though. Implementations could still do it, but as a heuristic, not part of the spec. That doesn’t seem ideal to me. Another option would be to revise it to be consistent with practice, as in when End-of-RIB has been sent for each address family supported by 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 a corresponding set of End-of-RIB messages, or Peer Down message, corresponding to each Peer Up message.) That’s cleaner but now the monitoring station has to go to the (minor?) trouble of keeping track of EoRs and reconciling them against AFs supported on the session. Yet another option would be to introduce a BMP-specific “end of initial BMP convergence” message that does what the current text suggests — a single message to say “done". That one smells the best to me, at the moment. It’s also the most intrusive. If someone in the GROW WG has the stomach to take this forward, it seems to me that the best option would be to write and progress either a small draft fixing the bug (with one of the approaches above, or something else), or a full rfc7885bis. As far as an erratum goes, there’s no clean way to do it :-( since it’s not a bug with a single, straightforward fix. I think what I’m going to do is open an erratum describing the bug, without supplying any proposed “corrected text”, and with the full discussion of the options in the comment part. Warren then gets the fun of deciding if it should be verified as “hold for document update”, or what. Thanks, —John > On Sep 12, 2022, at 4:36 PM, Jeffrey Haas <[email protected]> wrote: > > [External Email. Be cautious of content] > > > +grow, where BMP is standardized. > > On Sun, Sep 11, 2022 at 09:45:29PM +0200, Vincent Bernat wrote: >> Hey! >> >> In 3.3: >> >> 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.) >> >> The wording looks like the EoR is sent once per peer. However, an >> EoR is AFI/SAFI-dependent. Therefore, it is unclear if any EoR >> should signal the end of the initial table dump or if one EoR per >> family is needed. >> >> Looking at JunOS implementation, I see one EoR per family. > > It is indeed per family in Juniper's implementation for exactly the reasons > you mention. > > If the authors agree that was the intent, it's minimally worth an RFC Errata > covering the point. > > -- Jeff > > _______________________________________________ > Idr mailing list > [email protected] > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!A1ynY7YxND7J2FALzcYL8NWW6JRfMb91Tg-IgAuiyauDAcJR8UdiGL2icrHSzPj5CGrlz9LWGg$ _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
