[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
- [Idr] RFC7313 implementation details Claudio Jeker