[Idr] RFC7313 implementation details

Claudio Jeker <cjeker@diehard.n-r-g.com> Mon, 17 May 2021 14:49 UTC

Return-Path: <cjeker@diehard.n-r-g.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3320D3A3A99 for <idr@ietfa.amsl.com>; Mon, 17 May 2021 07:49:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.196
X-Spam-Level:
X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4OXNnH7g5Ux for <idr@ietfa.amsl.com>; Mon, 17 May 2021 07:49:51 -0700 (PDT)
Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF1DA3A3A92 for <idr@ietf.org>; Mon, 17 May 2021 07:49:50 -0700 (PDT)
Received: (qmail 3993 invoked by uid 1000); 17 May 2021 14:49:46 -0000
Date: Mon, 17 May 2021 16:49:46 +0200
From: Claudio Jeker <cjeker@diehard.n-r-g.com>
To: idr@ietf.org
Message-ID: <20210517144946.GA2814@diehard.n-r-g.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/XyknQ3MupXFLe-lCIWgDSPKfEuw>
Subject: [Idr] RFC7313 implementation details
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 May 2021 14:49:55 -0000

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