Display BGP gateway mode in show protocol output

[Alexander Zubkov]

I have checked now and actually found there are already some features in
BIRD marked experimental. So I'm not inventing anything new here. :)

On Thu, Sep 11, 2025, 00:17 Alexander Zubkov <green at qrator.net> wrote:

> Hi everybody,
>
> This thread has awaken some evil thoughts I have had since long ago. I
> know this might be forbidden here, but still, I could not sleep well until
> I did it. Please don't beat me for that. :)
> So here is the patch (applies to "thread-next" branch). It is definitely
> ugly, ineffective, untested, requires a lot of polishing, etc. It was
> mostly created as a proof of concept for now. It seems to be working at
> least on my simple tests with device, kernel, pipe, bgp protocols. With it
> you can send "json protocols" command and get a dump of protocols in JSON.
> It also adds "-q" option to cli to hide the "BIRD ..." header, so you can
> do things like:
>
> $ ./birdc -q "json protocols" | jq '.protocols.bgp1.Channels.ipv4["Gateway
> mode"]'
> "recursive"
>
> I know we all long for a great API to come. But unitl that we sill have to
> parse the text cli output. So why not to parse for example JSON isntead? :)
> It is safer to extend and not to break compatibility with text parsers.
> This and other benefits are mostly well-known. Of course it is ugly piece
> of code added to the codebase, that needs to be maintained, etc. All the
> minuses has also been well described here already. Anyway, I do not expect
> it to be included upstream, just had some strange need to do this coding
> exercise. :) On the other hand if it looks appealing, I can polish/improve
> it if needed. Also "routes" variant could be added.
> Any feedback is welcome! And I can give more comments on the contents, of
> course.
>
> PS. Also another idea has come to my mind. What BIRD team think about
> introducing a practice of adding experimental features, i.e. those that
> have no guarantee to remain compatible between versions, or to remain at
> all. It is often said that adding new features is a hard process because
> they need to be maintained, harden merges between versions, need thourough
> study right away because further redesign can break compatibility. So I
> think calling it experimental and giving yourself an opportunity to "undo"
> it, could break the tie and give some "sandbox" for the feature to mature
> or perish.
>
> PPS. I'm not advocating my json patch with that idea. :)
>
> Regards,
> Alexander
>
> On Wed, Sep 10, 2025 at 1:02 PM Douglas Fischer <fischerdouglas at gmail.com>
> wrote:
>
>>
>> https://gitlab.nic.cz/labs/uytc/-/blob/dirty/examples/00_leaf/expected.output
>> 😍
>>
>> Em ter., 9 de set. de 2025 às 20:56, Maria Matejka via Bird-users <
>> bird-users at network.cz> escreveu:
>>
>>> Hola!
>>>
>>> With that, there is some internal tooling work on the way (because
>>> people around Netconf didn’t bother to think about performance, let aside
>>> maintainability) and as soon we have this, at least an experimental API is
>>> gonna be there quite fast.
>>>
>>> The actual tooling is UYTC YANG To Code which should enable you to
>>>
>>> Doing google (not the best for this atm) on “UYTC YANG To Code” returns
>>> a I mistyped this it must be UTC YANG … the rest of the returned data is
>>> utterly garbage , Is there a url for this tooling you speak of ?
>>>
>>> Well, there is just a git repo with pieces of code in a very
>>> being-worked-on state. Not much to actually see for now, there are just
>>> several branches of dirty python code for now.
>>>
>>> https://gitlab.nic.cz/labs/uytc/
>>>
>>> Yet, this thing is, in the end, going to have a module for creating C
>>> code. But first we have to digest through all the funky RFCs around YANG,
>>> CBOR and whatever else blocks us, including drafting some new stuff, to
>>> make everything actually fly the reasonable way.
>>>
>>> Once, Donald E. Knuth said: »So, I just have this philosophy that there
>>> will be always some people who are more interested in quality than others,
>>> and I wanted to make TeX good for them.« (pg. 349
>>> https://www.tug.org/TUGboat/tb17-4/tb53knun.pdf)
>>>
>>> And we wanna make this right, and minimize the oversights which would be
>>> too late to fix later. The original architecture of BIRD was good for 20
>>> years, saved us a lot of hair, and many parts of it are actually still
>>> there.
>>>
>>> Maria
>>>
>>> –
>>> Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
>>>
>>
>>
>> --
>> Douglas Fernando Fischer
>> Engº de Controle e Automação
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20250911/35ef9ae8/attachment.htm>