Re: [Idr] Compatibility of draft-ietf-idr-bgp-model-16 with BIRD
Jeffrey Haas <jhaas@pfrc.org> Tue, 27 June 2023 16:40 UTC
Return-Path: <jhaas@slice.pfrc.org>
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 465C3C151532 for <idr@ietfa.amsl.com>; Tue, 27 Jun 2023 09:40:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z99x0rVZ04Hf for <idr@ietfa.amsl.com>; Tue, 27 Jun 2023 09:40:48 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8D44FC151542 for <idr@ietf.org>; Tue, 27 Jun 2023 09:40:47 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 2D8041E1D0; Tue, 27 Jun 2023 12:40:47 -0400 (EDT)
Date: Tue, 27 Jun 2023 12:40:46 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Maria Matejka <maria.matejka=40nic.cz@dmarc.ietf.org>
Cc: "idr@ietf.org" <idr@ietf.org>
Message-ID: <20230627164046.GA30404@pfrc.org>
References: <4d2822d3-251a-f2ae-bc9c-b7fa58ea75ed@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4d2822d3-251a-f2ae-bc9c-b7fa58ea75ed@nic.cz>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/9jntIjnYySW0gIn65JqKds62IdA>
Subject: Re: [Idr] Compatibility of draft-ietf-idr-bgp-model-16 with BIRD
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 27 Jun 2023 16:40:53 -0000
Maria, Apologies for response latency. I'm taking some well-needed vacation and I'm mostly out of touch until start of next week. However, I have a bit of connectivity today and wanted to at least partially advance this thread. On Wed, Jun 21, 2023 at 08:11:12PM +0200, Maria Matejka wrote: > We are finally trying to adopt the draft-ietf-idr-bgp-model-16 in > BIRD and we are struggling a lot with the structures proposed. I > haven't yet fully parsed the draft, so I'm now just writing several > concerns which I see with my current knowledge. Thanks for the work. Implementation is most likely to shake loose the interesting issues. > > 1. We don't index BGP neighbors by IP addresses, we name them by > user-defined strings. It's possible (at least in testing setups) > that there are multiple (possibly hundreds) BGP neighbors on the > same IP address just with a different port, configured on the other > side as passive. Does it make sense to somehow "extend" this in our > BGP-YANG extension, or should we try to "upstream" this to the draft? This is actually a critical detail to resolve as early as possible since keys inside of lists aren't subject to revision according to YANG rules. It's a very non-backward-compatible change. There's also a bit of history for controversy on such keying. The RFC 4273 MIB keys only on the remote peer address - and only for IPv4 since that's all that MIB was able to support. There was ancient work (one of my first IETF projects) to try to update the MIB for IPv6 and "fill in the gaps" for missing functionality. This was covered by draft-ietf-idr-bgp4-mibv2. It was also sadly my introduction to "IETF doesn't necessarily know what it wants". So, the MIB wandered around competing requirements from the IETF ops community to try to make BGP configurable, and also properly cover the state BGP carries. One structural change early in that MIBv2 work prior to -09 was that neighbors were indexed by local and remote addresses rather than solely remote address. This would at least permit more than one peering session between two routers when the same remote address was being used. There was discussion, but no work done, to also permit the ports to be included as part of the key. The eventual consensus from the working group was "BGP runs on port 179, don't worry about modeling anything else". If BIRD has support for RFC 4273, it likely already has a flavor of the issue you're discussing already. Similarly, the OpenConfig YANG module for BGP also uses the remote address. I agree the type of test scenario you're describing can happen and can't be accommodated in the current model. It's unclear what an appropriate change might be to add the flexibility you're looking for without potentially causing other issues in the module where keys are expected to be shared for the neighbor entry. We'd certainly discuss potential patches you may have. YANG has much more flexibility than SMIv2 did for MIBs and much of the reason we left MIBs behind was that lack of flexibility. > 2. Our policies are quite a free-form short scripts which can't be > straightforwardly represented in this YANG, and I'm very afraid that > we just fail to represent our more intricate filters in anything > compatible with this YANG at all. The current bgp-specific policy in this module is intentionally skeletal and doesn't cover all possible current policy engines. YANG does permit extending the policy using augmentation, but there's some expectation that the skeleton used by the IETF routing policy module is reasonable for your implementation. If that skeleton is completely inappropriate, there's probably a much larger conversation covering that point. > 3. There are several occurences of this regex, attempting to represent > 32-bit integers (e.g. at page 117): > '(4[0-2][0-9][0-4][0-9][0-6][0-7][0-2][0-9][0-6]|' > + '[1-3][0-9]{9}|[1-9]([0-9]{1,7})?[0-9]|[0-9])' > which doesn't e.g. match 4199999999; also another regex on page 119 > (bgp-ext-community-type) mismatches 16-bit integers, like 64999; > curiously, another regex on page 125 (bgp-set-med-type) does the > 32-bit integers right. Feel free to open an issue on the github for the module and we'll address it. If you've not opened one after I've returned from holiday, I'll do so. Using POSIX-style regex to cover range restrictions in YANG is probably one of my less favorite quirks of the language because it makes it easy to have bugs like this. > 4. Also the large community representation seems to not allow any > binary format (page 117) which is strange in my eyes. You likely have noticed that extended communities have a lot of work around them to try to provide a level of flexibility. However, they were challenging to get "right" in the current flavor and even now will make a number of people managing the YANG language unhappy about their maintenance. What would you propose for the "binary" formats for large communities? > I explicitly state that this is not the full list of my concerns, > I'm trying to get at least some grip on this so if there was anybody > to point me the right way to approach this, I'd be really happy. IDR list discussion is certainly one way to do it. The github is another using issues, although anything besides simpler maintainance will eventually revert to IDR list discussion. And should you, or others working on the project, be coming to the upcoming IETF, I'm sure the module authors can spend some time on open discussion on the module. -- Jeff
- [Idr] Compatibility of draft-ietf-idr-bgp-model-1… Maria Matejka
- Re: [Idr] Compatibility of draft-ietf-idr-bgp-mod… Jeffrey Haas
- Re: [Idr] Compatibility of draft-ietf-idr-bgp-mod… Maria Matejka