<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<meta name="generator" content="pandoc" />
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes" />
<style>
html {
line-height: 1.2;
font-family: serif;
font-size: 0.9em;
color: black;
background-color: white;
}
body {
margin: 0;
margin-right: auto;
max-width: 36em;
padding: 1em;
hyphens: auto;
overflow-wrap: break-word;
text-rendering: optimizeLegibility;
font-kerning: normal;
}
@media print {
body {
background-color: transparent;
color: black;
font-size: 11pt;
}
p, h2, h3 {
orphans: 3;
widows: 3;
}
h2, h3, h4 {
page-break-after: avoid;
}
}
p {
margin: 1em 0;
}
a {
color: black;
}
a:visited {
color: black;
}
img {
max-width: 100%;
}
h1, h2, h3, h4, h5, h6 {
margin-top: 1.4em;
}
h5, h6 {
font-size: 1em;
font-style: italic;
}
h6 {
font-weight: normal;
}
ol, ul {
padding-left: 1.7em;
margin-top: 1em;
}
li > ol, li > ul {
margin-top: 0;
}
blockquote {
margin: 0.5em;
padding-left: 0.5em;
border-left: 2px solid #e6e6e6;
color: #444;
}
code {
font-family: 'Lucida Console', monospace;
font-size: 95%;
margin: 0;
}
pre {
margin: 1em 0;
overflow: auto;
max-width: unset;
width: fit-content;
}
pre code {
padding: 0;
overflow: visible;
overflow-wrap: normal;
max-width: unset;
white-space: pre-wrap;
}
pre code span {
white-space: pre;
}
.sourceCode {
background-color: transparent;
overflow: visible;
}
code.diff span.kw,
code.diff span.dt {
font-weight: bold;
}
code.diff span.va {
background-color: rgba(192, 255, 192, 64);
color: rgb(0, 64, 0);
}
code.diff span.st {
background-color: rgba(255, 192, 192, 64);
color: rgb(64, 0, 0);
}
pre.diff {
background-color: rgb(240, 240, 240);
padding: 0.4em;
border: 1pt solid grey;
}
hr {
background-color: black;
border: none;
height: 1px;
margin: 1em 0;
}
table {
margin: 1em 0;
border-collapse: collapse;
width: 100%;
overflow-x: auto;
display: block;
font-variant-numeric: lining-nums tabular-nums;
}
table caption {
margin-bottom: 0.75em;
}
tbody {
margin-top: 0.5em;
border-top: 1px solid black;
border-bottom: 1px solid black;
}
th {
border-top: 1px solid black;
padding: 0.25em 0.5em 0.25em 0.5em;
}
td {
padding: 0.125em 0.5em 0.25em 0.5em;
}
header {
margin-bottom: 4em;
text-align: center;
}
code{white-space: pre-wrap;}
span.smallcaps{font-variant: small-caps;}
span.underline{text-decoration: underline;}
div.column{display: inline-block; vertical-align: top; width: 50%;}
div.hanging-indent{margin-left: 1.5em; text-indent: -1.5em;}
ul.task-list{list-style: none;}
q { quotes: "„" "”" "»" "«"; }
.display.math{display: block; text-align: center; margin: 0.5rem auto;}
</style>
</head>
<body>
<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 https://github.com/pawelmaslanka/RoutingConfigApi
. 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>
</body>
</html>