<div dir="ltr">Hi Alexander, David and Sébastien!<br>Sorry to butt in on this, but this is a topic that really interests me.<br><br>Again, just to give you some context, I'm not a programmer!<br>Just a lazy network operator (in a good way) who sometimes tries to build his own tools to make his life easier.<br><br>About the patch brought by Sébastien<br>I learned a while ago (the hard way) that parsing outputs is the worst way to interact with other software. And even though it's terrible, sometimes it's the only way we have left.<div>I don't think attaching too many things to birdc right now is wise, but I understand your pain.<br><br><br>David, Maria, Ondrej<br>I've been hearing about initiatives in this work regarding the BIRD API.<br>I think the place I see this mentioned most often is on Alice-LG.<br>But I end up not seeing anything in detail about it because I don't have the time I'd like to dedicate to learning by reading code from projects like Bird.<br><br>I'm wondering how this is being planned, and I imagine other lay people like me are also curious about it.<br>So I decided to ask if the BIRD team could tell me more about this.<br>- In the time I've been following the list, I remember several times the conversations pointed to the direction of netconf/yang.<br>- I also remember a mention of a no-go for gRPC and gNMI, but I don't remember the details.<br>- I also remembered <a href="https://github.com/pawelmaslanka/RoutingConfigApi">https://github.com/pawelmaslanka/RoutingConfigApi</a> . I confess I didn't analyze anything, but I think it deserves a mention.<br>- And briefly, I remembered that every time XML or JSON was mentioned, Eustace Bagge appeared here on the list. lol.<br><br>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.<br><br>Thank you in advance.</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Em sex., 5 de set. de 2025 às 14:09, Alexander Zubkov via Bird-users <<a href="mailto:bird-users@network.cz">bird-users@network.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 dir="ltr"><div dir="auto"><div>Hi all!<div dir="auto"><br></div><div dir="auto">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?</div></div><div><br></div><div>Regards,</div><div>Alexander</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 5, 2025, 16:04 David Petera via Bird-users <<a href="mailto:bird-users@network.cz" target="_blank">bird-users@network.cz</a>> wrote:<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>
    <p>Hello Sébastien!<br>
      <br>
      Thanks for sending us these patches, but unfortunately it would <b>not</b>
      be wise to change BIRD's CLI output right now.<br>
      <br>
      We discussed it in our team and the the primary reason is this:<br>
      <br>
      Since BIRD does not yet have well defined API for communication,
      most automation and tooling around BIRD (including our own) relies
      on the exact format of the CLI output.<br>
      These changes would/could break the tooling around BIRD and cause
      lot of headache for little gain.<br>
      <br>
      We know that this situation is not ideal and thus API for BIRD is
      being worked on. <br>
      Once finished we can improve the CLI output without major
      consequences.<br>
      <br>
      Hope you understand, why we can not accept these patches right
      now.<br>
      <br>
      Wish you a great weekend and happy routing!<br>
      David<br>
    </p>
    <pre cols="72">David Petera (he/him) | BIRD Tech Support | CZ.NIC, z.s.p.o.</pre>
    <div>On 8/25/25 14:35, Sébastien PARISOT
      wrote:<br>
    </div>
    <blockquote type="cite">
      <pre>Hello BIRD team!

This simple patch (for branch master) adds a field for the BGP channel gateway mode (direct or recursive) setting in show protocol output. It is is a useful information to have in some troubleshooting scenario.

Example:

bird> show protocol all bgp_test
Name             Proto      Table                        State  Since                Info
bgp_test           BGP        ---                          up     2025-08-12 15:11:54  Established   
  BGP state:          Established
[...]
  Channel ipv6
    State:          UP
[...]
    Gateway: recursive
[...]

Thanks!
--
Sébastien</pre>
    </blockquote>
  </div>

</blockquote></div></div></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>