Subject: [Idr] RFC7313 implementation details

From: Claudio Jeker <[email-masked]>
Date: Mon, 17 May 2021 16:49:46 +0200

Hi IDR,

I'm finalizing the implementation of enhanced route refresh and would like
to know how other systems handle a few details in RFC7313.

- Does "Enhanced Route Refresh" depend on the presence of RFC2918 (normal
  route refresh) capability? Are both capabilities needed to enable
  enhanced route refresh or is it enough to just announce enhanced route
  refresh.

- On session without Graceful Restart will the initial table dump be put
  in BoRR and EoRR messages? There will be no EoR marker and so the
  procedures in the last paragraph of section 4 do not apply.

- What kind of default timeout as the upper bound for a refresh operation
  is used if one is used at all?

- How was the possible overflow of data in the invalid length notification
  (error 7, subcode 1) handled?
  The RFC specifies:
    If the length, excluding the fixed-size message header, of the
    received ROUTE-REFRESH message with Message Subtype 1 and 2 is not 4,
    then the BGP speaker MUST send a NOTIFICATION message with the Error
    Code of "ROUTE-REFRESH Message Error" and the subcode of "Invalid
    Message Length".  The Data field of the NOTIFICATION message MUST
    contain the complete ROUTE-REFRESH message.
  It is impossible to include a maxium sized ROUTE-REFRESH message into
  a NOTIFICATION message. At what point do implementation trunkate the
  message? Does it make sense to send 4000bytes of data payload for
  something where 4 bytes is expected?

Thanks in advance for any insight on these points.

Regards,
-- 
:wq Claudio