From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40]) by lore.proxmox.com (Postfix) with ESMTPS id 6FF541FF0AE for ; Tue, 01 Sep 2026 10:55:00 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 8F07021545; Tue, 01 Sep 2026 10:54:59 +0200 (CEST) Message-ID: Date: Tue, 1 Sep 2026 10:54:54 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH docs/gui-tests/manager/network/proxmox{-ve-rs,-perl-rs} v3 00/13] Add IS-IS protocol to fabrics To: pve-devel@lists.proxmox.com References: <20260828113255.176546-1-g.goller@proxmox.com> From: Hannes Laimer Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1788252892451 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.736 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: 3MNLEGHVAZZG632QKT2JGS6BYBHRGTVQ X-Message-ID-Hash: 3MNLEGHVAZZG632QKT2JGS6BYBHRGTVQ X-MailFrom: h.laimer@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 2026-09-01 10:33, Gabriel Goller wrote: > On 01.09.2026 09:09, Hannes Laimer wrote: >> On 2026-08-31 14:59, Gabriel Goller wrote: >>> On 31.08.2026 14:27, Gabriel Goller wrote: >>>> On 31.08.2026 10:48, Hannes Laimer wrote: >>>>> Aside from these very tiny nits/questions, looks very good to me: >>>>> - could we have the same `network_type`-nob here that we introduced for >>>>> OSPF? >>>> >>>> Yes, makes sense. ISIS supports network-type broadcast (unlike openfabric) and >>>> even multi-access (e.g. multiple devices behind a switch). >>> >>> Oh, no wait I won't be adding this. ISIS only has broadcast and point-to-point >>> available, and the default is broadcast. We use broadcast when an interface ip >>> is set and point-to-point when no ip is set. >>> >> >> yes, but we only need a specified ip for v4 broadcast, v6 does not. so >> unnumbered v6 broadcast is not possible currently > > Hmm that's true. v6 broadcast works in two scenarios: link-local addresses > (which IMO is not "unnumbered" -- but this is debatable :)), and because it uses > ndp instead of arp, which doesn't have the weird address-selection. > > I thought a while back about this -- we don't need to duplicate the ipv6 > addresses to the interface. But then we should also remove the link-local > addresses to make it clean. i don't think we can, the ll would be the next-hop.. > >> the ip for the nic is taken from the node config, so leaving the nic ip >> fields empty doesn't necesarrily mean do p2p, p2p still needs a >> next-htop target and for v4 this has to be specified. we just take the >> ip from the node, which is fine. but leaving the ip field empty does not >> imply do `p2p`, just: use the node-ip for either(p2p or broadcast). >> >> for v6 we could actually never copy the node-ip to the nic(we do that >> now always), this would allow configuring unnumbered v6 broadcast or >> p2p, which are both possible with v6. >> >> does isisd support v4-via-v6 routes? if it does we could just do v6 >> unnumbered in case no nic ip is specified and skip configuring the nic >> ourself.. > > Nope. :/ > >> either way, I still think the nob makes sense here, cause the the >> existance of a specified ip on the nic doesn't really point either way >> (bc or p2p), both need one, and for v6 can work without one > > Hmm yes you're right. We could add a knob like with ospf, where we have "auto" > (the current heuristic to select network-type) and then "point-to-point" and > "broadcast". sounds good, im just not sure if 'auto' could be interpreted as 'find out if there is multiple in this L2 domain'.. since this would be new, maybe just the two explicit choices might be better, but fine either way > >>>>> - the warning in the UI could be warpped in a `gettext()` >>>> >>>> Agree. >>>> >>>>> - could we put `isisd => 1` behind an IS-IS fabric presence check? i >>>>> guess that could break setups that have it enabled manually though.. >>>> >>>> Hmm you're right I missed this. I somehow thought we always have it enabled like >>>> bgpd, but turns out the user needs to manually enable it. >>>> >>>> [snip]