<div dir="ltr">Hello Maria!<br>Thank you very much for your thoughtful reply.<br><br>Even though I'm a layman, I can clearly understand the constraints and difficulties the BIRD team is currently facing.<br><br>I completely agree with the option of not embedding an HTTP layer. That's not the role of a routing daemon.<br><br>On the other hand, I see that there's no way to leave BIRD without enabling this type of more standardized interaction with configurations and monitoring. Which leads me to believe it makes sense to consider finding a solution for this through a set of other software.<br>I know almost nothing about programming, but I see that in one way or another, tools like ARouteServer, birdwatcher, pathvector, or RoutingConfigApi... are already doing this, the hard way, but they do it.<br>I imagine it makes sense for there to be some kind of intermediate layer that can be used by software like the ones mentioned.<br><br>Another point that came to mind is the use of BIRD in Kubernetes CNI environments. I remembered Calico using BIRD 1.6[1].<br>I don't even know if they still use that version. But I'm willing to bet that maintaining the legacy version has something to do with this parsing effort.<br>If I understand correctly... They somehow use confd to retrieve the necessary objects and attributes from etcd and assemble the bird configuration. And in the same way, they cyclically compare these two things to implement some configuration resync.<br><br>[1] P.S.: Does anyone have any information on whether Tigera has commented on this? Did they look for newer versions?</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Em sáb., 6 de set. de 2025 às 07:59, Maria Matejka <<a href="mailto:maria.matejka@nic.cz">maria.matejka@nic.cz</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg-4133268648013856276"><u></u>


  
  
  
  

<div>
<p>Hello!</p>
<p>On Sat, Sep 06, 2025 at 07:19:54AM -0300, Douglas Fischer wrote:</p>
<blockquote>
<ul>
<li>In the time I’ve been following the list, I remember several times
the conversations pointed to the direction of netconf/yang.</li>
</ul>
</blockquote>
<p>We expect to implement a superset of a subset of coreconf/yang.</p>
<p>There might be a possibility to attach a netconf-coreconf or
restconf-coreconf intermediate, yet we don’t expect implementation in
the daemon itself because of performance reasons.</p>
<blockquote>
<ul>
<li>I also remember a mention of a no-go for gRPC and gNMI, but I don’t
remember the details.</li>
</ul>
</blockquote>
<p>The main problem with API is the internal binding and data gathering
from the internal structures. That’s either a tedious error-prone manual
labour, or a tedious binding specification, or both, all with uncertain
performance outcome.</p>
<p>The other part is HTTP, which is the transport layer under gRPC (and
gNMI). That is something we don’t like having inside a routing daemon,
and the more I’m reading Daniel Stenberg’s blog, the more I’m convinced
that we should never allow HTTP inside BIRD.</p>
<blockquote>
<ul>
<li>I also remembered <a href="https://github.com/pawelmaslanka/RoutingConfigApi" target="_blank">https://github.com/pawelmaslanka/RoutingConfigApi</a>
. I confess I didn’t analyze anything, but I think it deserves a
mention.</li>
</ul>
</blockquote>
<p>Haven’t yet studied but it’s in the queue.</p>
<blockquote>
<p>Even though JSON and gRPC are somewhat forbidden topics here, I’d
like to ask if they ever considered using LSP (which isn’t the MPLS LSP,
haha). Language Server Protocol. I was close to a project where a friend
who used LSP transformed a specific software API into something almost
like its own CLI, with smart autocompletes and other very advantageous
features from the operator’s perspective.</p>
</blockquote>
<p>I’m completely unaware of that. Could you please provide a link to
that thing doing that with API? What I could find by quick search, was
just smart programming language autocompletion.</p>
<blockquote>
<blockquote>
<p>What about adding a selector to show only certain kind of
“something”. “Something” - because there is no actual way to show
channels, and a protocol can contain mixed channel types, so we cannot
filter “show protocol” by channel type. But I think it is possible to
add a selector for routes to see only direct/recursive ones. If we
cannot mark them in the output because of the compatibility, we can at
least select only certain kind to know who is who. I think it could be
even not “show route …” selector, but some route attribute to be used in
a filter. Maybe being able to understand the kinds of the routes would
work for Sébastien too?</p>
</blockquote>
</blockquote>
<p>Yes, adding a route selector this way should work; in BIRD 3, you may
probably ask by a filter like <code>where defined(hostentry)</code> but
I’m not sure whether this attribute is actually exported to filters in
any way. If not, this may be quite an “easy” update to
<code>filter/f-inst.c</code> for both BIRD 2 and 3, worth
contributing.</p>
<p>Note: We have to refactor the nexthop implementation quite heavily
soon; with the upcoming EVPN support there are things getting much more
hacked in than before, and we are slowly but surely converging to
maintenance hell.</p>
<p>There is still an awful lot of work to do on BIRD, and as I said at
RIPE 90, one can’t expect anybody to contribute “externally” a
large-scale refactoring needed to implement things well, because that
work needs coordination, time, flexibility and very high frustration
tollerance.</p>
<p>Hoping that this helps.</p>
<p>Maria</p>
<p>–<br>
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.</p>
</div>

</div></blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Douglas Fernando Fischer<br>Engº de Controle e Automação<br><div style="padding:0px;margin-left:0px;margin-top:0px;overflow:hidden;color:black;text-align:left;line-height:130%;font-family:"courier new",monospace"></div></div></div>