1. The latest proposal draft: 
   Page 72-73 `Retrieve Operational Data - Retrieving Containers and Leaf members`
   Page 84-85 `Retrieve Operational Data - Retrieving Large List elements` + comments
   Page 86 `Retrieve Operational Data - Retrieving Containers and Leaf members` + comments.

2. Scaling issues and risk of segfaults
   The current configuration interface does not scale well.
   Once operating with massive objects (100k+ routes at a time, etc..), frr runs a high risk to segfault.
   Because of this issue, they are not displaying the routing table on UI after a certain threshold.
-  Current target is to be able to query 1 million BGP routes without segfaults
-  The next step: each route should have 4/8/16 next-hops, meaning UI will receive 4/8/16 * 1mill objects

3. Chunk size.
-  My implementation introduces the `max-elements` option that limits the number of requested data.
   It may be updated on the following requests with `next` option, i.e.:
        show yang operational-data <path> max-elements 10 zebra
        show yang operational-data <path> max-elements 100 next zebra

-  In current MGMTD implementation, the batch has a fixed size.
   mgmt_defines.h:
       #define MGMTD_MAX_NUM_XPATH_REG 128
       #define MGMTD_MAX_NUM_DATA_REQ_IN_BATCH 32
       #define MGMTD_MAX_NUM_DATA_REPLY_IN_BATCH 8

   According to `Pushpasis,` the aim is for the backend daemon to decide how much data it can send at the moment.
   It is possible to introduce fixed-size requests into MGMTD, but that will need the community consensus.
   For more details, check the doc pages described in [1]

4. GUI connection to the FRR.
-  My expectation was that client would send the request whenever it want the additional data.
-  In the MGMTD, the daemon triggers the fronted client callback until the entire object is returned
   For more details, check the doc pages described in [1]

5. Timeline. The feature has been in development for two years, and it will take a lot of time to finish.
   He had mentioned a case when they came to an agreement with the community on some design choices but
   it was dropped later in the discussion, therefore considerably reverting the progress.

   Once the MGMTD core is finished, all of the demons should be moved to Northbound data models
   and architecture. Unfortunately, many demons don`t have a data model designed/developed, i.e. `bgp`.

6. Testing
    Currently, they are testing the MGMTD by feeding a configuration file to vtysh with 10k of static routes.
    Actually, the frr has a separate demon for scale testing called `sharpd`, but it is not connected to the infrastructure

1. Stabilization
-  I have seen a corner case that would crash inside the northbound callbacks.
-  I can see some validation failure logs, although the resulting output seems good for me.
-  Daniil was concerned about memory leaks associated with iteration state.
   After additional research - this is not a problem, but I can imagine cases where we would
   fail to handle a malformed XPath and leak resources on the stuck unwinding
   I need to do some testing with Valgrind.
2. Scale testing
3. Async support for multiple vtysh clients. The current demo assumes that there is only one client.
   I want to map the iteration state to the vtysh client/socket so multiple requests may be executed in parallel
4. A debugging instruction
   I have used some complicated debugging flow when merging the feature.
   This should be useful for other (non-C) devs.
5. Finishing the documentation
6. advanced XPath filtering support?

1. I have removed the global iterator and incapsulated the iteration state into the vty structure.
   This way, each vtysh client has its private iteration state for the following requests.
   It should be possible to query multiple data nodes simultaneously and asynchronously.

   The overhead is two buffers of 1024 bytes to keep track of the requested XPath and offset.

2. Since vty keeps track of the previously requested arguments, there is no need to explicitly specify
   them on the `next` requests. So that usage pattern becomes:
     $ show yang operational-data <xpath> max-elements <n1> <daemon>
     $ show yang operational-data next <daemon>

   As well, it is possible to modify the query size for each request individually
      $ show yang operational-data next max-elements <n2> <daemon>

3. The current implementation is decent enough for the testing/prototyping, although it requires
   additional testing before it can be used in production.
   The changes to CLI argument order might have corner cases that I have missed.
   The same applies to the asynchronous handling that should be tested for scaling/etc...

   The test plan will be presented once the API is finalized.

# generate build config
$ debian/rules
$ make -j $(nproc --all)
$ sudo make install
$ service frr stop
$ service frr start

https://github.com/FRRouting/frr/commit/d8f4aad06b33bb23a98c2dd8d6b2c0ad30636b5d

--enable-static-bin \
--enable-static \
--enable-shared \
--enable-dev-build \

Start the first instance of FRR, however, your OS does it.
    On Archlinux, this is: sudo systemctl start frr
Setting up another netns and interface
    Create a network namespace (ns) named blue (or any other name): ip netns add blue
    Verify it: ip netns list
    Create two interfaces ip link add veth0 type veth peer name veth1
    Verify the two appear: ip link list
    Move veth1 from the global ns to the blue ns: ip link set veth1 netns blue
    Verify that veth1 is gone from the global ns: ip link list
    Verify that veth1 appears in the blue ns: ip netns exec blue ip link list
Create a copy of /etc/frr, move it to a new directory: /etc/frr/blue
In /etc/frr/blue/daemons, set the blue ns: #watchfrr_options="--netns=blue"
Start the second instance of FRR: /usr/lib/frr/frrinit.sh start blue
vtysh into them, and verify veth0 and veth1 appear in the first and second instance respectively
    First: sudo vtysh, then show interface veth0
    Second: sudo vtysh -N blue, then show interface veth1
To stop the second instance of FRR: /usr/lib/frr/frrinit.sh stop blue

1. The `master` version is built on the host device and runs within the `blue` network namespace
2. The `legacy` version is built within the docker.
   Since docker doesn`t support the `systemd`, the package is configured with `--enable-systemd=no`
   After installation, it can be triggered with `frr/tools/frrinit.sh stop/start`
   Since there is no `journald`, you want to redirect the log to the local file
------------------------------------------------------------------------------------------------------
        /etc/frr/frr.conf:  log file /home/vova/frr.log
        touch /home/vova/frr.log
        chmod 777 /home/vova/frr.log
------------------------------------------------------------------------------------------------------

3. Once finished, the docker will leak the process into the host process space, meaning you can attach
   to it using gdb from the host (there is no need for gdbserver + target remote).
   Although, be careful to not confuse the processes
------------------------------------------------------------------------------------------------------
    ps aux | grep /frr/
    # -N blue present, master frr
    root     ...  /usr/lib/frr/watchfrr -N blue -d -F traditional --netns=blue zebra staticd
    frr      ...  /usr/lib/frr/zebra -N blue -d -F traditional -A 127.0.0.1 -s 90000000
    frr      ...  /usr/lib/frr/staticd -N blue -d -F traditional -A 127.0.0.1

    # -N blue missing, docker frr
    root     ...  /usr/lib/frr/watchfrr -d -F traditional zebra staticd
    systemd+ ...  /usr/lib/frr/zebra -d -F traditional -A 127.0.0.1 -s 90000000
    systemd+ ...  /usr/lib/frr/staticd -d -F traditional -A 127.0.0.1


   # attaching to the master version in blue namespace
   sudo gdb -p $(pgrep  -f "zebra.*blue")

   # attaching to the legacy version in the docker
   sudo gdb -p $(pgrep  -f "/usr/lib/frr/zebra -d")
------------------------------------------------------------------------------------------------------

(gdb) b ly_log_cb
# NOTE: frr commands are generated with the _magic suffix
(gdb) b show_yang_operational_data_magic
(gdb) cont
        ....

rwatch [-l|-location] expr [thread thread-id] [mask maskvalue]
Set a watchpoint for an expression. GDB will break when the expr is written into by the program and its value changes

awatch [-l|-location] expr [thread thread-id] [mask maskvalue]
Set a watchpoint that will break when expr is either read from or written into by the program.

    (gdb) watch errno
    (gdb) watch ly_errno
    (gdb) watch *0xdeadbeef

 static void break_point(void) {};
 ....

 if (... NOT_OK ...)
     break_point();
 ....

As it can be seen, the function does nothing, but this will work as a hook if the program is connected
ot the gdb and the breakpoint was configured via `b break_point`

   I.e., this is useful when you are trying to understand the result difference when executing the
        same API with different arguments
   Though, it is highly likely that you will crash the gdb instance with a bad function call.
--------------------------------------------------------------------------------------------------------------
   (gdb) b break_point
   (gdb) cont
        ....
   (gdb) p (struct lyd_node *)lyd_new_path2(NULL, ly_native_ctx, xpath, NULL, 0,
                           0, 0, &dbg_parent, &dnode);

   (gdb) p (struct lyd_node *)lyd_new_path2(dnode, ly_native_ctx, xpath, NULL, 0,
                           0, 0, &dbg_parent, NULL);

        ....


NOTE: you need to stop the gdb session before restarting the daemon otherwise it will crash and stop
      responding

index.html
---------------------------------------------
<js>

    data = AJAX.request("xpath", "max_size")
    display(data)

    function dataUpdate(...) {
        html = jquery.find("xpath")
        data = AJAX.request("next")
        if (!data)
            return

        /* enque the data update */
        display_update(html, data)
        window.setTimeout(1000, dataUpdate)
    };

    window.setTimeout(1000, dataUpdate)

</js>

1. Strategy used to move between the solutions
2. Data output differences
   - my solution works with json/xml formats
   - the mgmtd work with a `yang tuple`
   [  "xpath1" : value1,
      "xpath2" : value2,
      ...
   ]
3. Differences between DBs (config:true vs config:false)
4. Evaluate the Datamodel coverage for the features of interest
5. Data control flow differences
6. Extended XPath filtering for complex data manipulations, i.e.
   https://pastebin.com/raw/GJG3QcAf
7. ??

vtysh -c "show yang operational-data /frr-vrf:lib/vrf[name='default']/frr-zebra:zebra/ribs zebra" > big.json

jq -c '."frr-vrf:lib" .vrf[0] ."frr-zebra:zebra" .ribs .rib[0] .route[]' big.json | split -l 100 -d

This is a full fledge implementation for retrieving operational state/data from one (or more) backend
component (provided the component already supports providing operational state through northbound layer).
This was based on the architectural/design discussions on MGMTd we had way back in 2021.
This PR completes the work needed on the MGMTd daemon and the MGMT backend client library needed for
MGMTd to get operational data from or one or more backend clients corresponding to the single GET-DATA
request received on front-end interface.