Beyond release 1.9.3

[ipspace]

1.9.3 (released today) was the last 1.9.x feature release (the real reason: release notes are getting too long 😜), the next one will be 2.0.

Because we're going to a new major release, we can afford to remove a bit of the old cruft like VirtualBox (#1788) and add major new things like #1481. Any other "revolutionary" ideas in either direction? /cc @jbemmel @ssasso @ddutt @sdargoeuves @steffann @DanPartelly @ubaumann?

Migration notes:

• I'll create a maint-1.9.4 branch to collect cherry-picked bug fixes of old stuff and will use it to generate 1.9.3-postX or even 1.9.4 (bug fix only) releases. Please make sure you fix old stuff in separate commits/PRs.
• Documentation fixes of old stuff will be cherry-picked into master branch (because we use that to generate documentation). Yet again, please fix old stuff in separate PRs.
• If needed, I'll merge the master branch into the dev branch around the 2.0.0-dev1 timeframe. I don't want to do massive rebases.

Everyone OK with the above? Any suggestions?

[steffann]

Sounds good. Let me think about crazy suggestions :)

[jbemmel]

Netlab has a strong validated data model on the configuration side, but not (yet) on the state side. To complete the loop on network automation, I'd like to see Netlab introduce a vendor agnostic state model, with focus on the bits that are required to reverse engineer a running network and generate a Netlab topology file that corresponds to what's deployed

netlab discover with an inventory file containing credentials would query the devices, map them to the correct vendor model, explore things like LLDP, OSPF and BGP neighbors and proceed to discover those nodes (provided credentials are available to access them)

[steffann]

Ooooh, that would be very useful! Especially when using netlab for training purposes to see where the students messed up :)

[ddutt]

Thanks to all for this release. mlag addition is useful. For my use cases, netlab is already doing pretty much everything I need. I'll think a bit more.

…

On Thu, Jan 9, 2025 at 12:40 AM Ivan Pepelnjak ***@***.***> wrote: 1.9.3 (released today) was the last 1.9.x feature release (the real reason: release notes are getting too long 😜), the next one will be 2.0. Because we're going to a new major release, we can afford to remove a bit of the old cruft like VirtualBox (#1788 <#1788>) and add major new things like #1481 <#1481>. Any other "revolutionary" ideas in either direction? /cc @jbemmel <https://github.com/jbemmel> @ssasso <https://github.com/ssasso> @ddutt <https://github.com/ddutt> @sdargoeuves <https://github.com/sdargoeuves> @steffann <https://github.com/steffann> @DanPartelly <https://github.com/DanPartelly> @ubaumann <https://github.com/ubaumann>? Migration notes: - I'll create a *maint-1.9.4* branch to collect cherry-picked bug fixes of old stuff and will use it to generate 1.9.3-postX or even 1.9.4 (bug fix only) releases. Please make sure you fix old stuff in separate commits/PRs. - Documentation fixes of old stuff will be cherry-picked into *master* branch (because we use that to generate documentation). Yet again, please fix old stuff in separate PRs. - If needed, I'll merge the *master* branch into the *dev* branch around the *2.0.0-dev1* timeframe. I don't want to do massive rebases. Everyone OK with the above? Any suggestions? — Reply to this email directly, view it on GitHub <#1789>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGIXE2VRP4ZXUADDRWAGMT2JYYY5AVCNFSM6AAAAABU3T3UQGVHI2DSMVQWIX3LMV43ASLTON2WKOZSG43TOMJXHA2TEMQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ipspace]

I'd like to see Netlab introduce a vendor agnostic state model, with focus on the bits that are required to reverse engineer a running network and generate a Netlab topology file that corresponds to what's deployed

That sounds like a great companion project that would generate netlab topology file as a result of the network discover. There are tons of open-source network discovery tools, someone "just" has to create the translation layer ;)

[ipspace]

Ooooh, that would be very useful! Especially when using netlab for training purposes to see where the students messed up :)

You already use netlab validate to figure that out, and if you can define what devices the students use (and if those devices can generate JSON printouts) it becomes almost trivial:

• Figure out what show commands to use (show parameter in a validation test)
• Use those show commands to generate JSON data structures
• Figure out what parameters to check in those JSON data structures
• Convert that into a Python expression (valid parameter in a validation test)

BGP and IS-IS labs are trying to solve a somewhat harder problem: determine whether the student did the right job without having access to the student device (because they can use any netlab-supported device). Not surprisingly, the results are good but not perfect.

[jbemmel]

You already use netlab validate to figure that out, and if you can define what devices the students use (and if those devices can generate JSON printouts) it becomes almost trivial

That's my point: Netlab has an abstraction layer for the configuration model, but not for the state model. Users are left to figure out which show commands to use, and how to parse the output.

What's missing in my view, is a data model for the state. Once we have that, it would also be used for validation

For example, from https://github.com/ipspace/netlab/blob/dev/tests/integration/ospf/ospfv2/31-priority.yml

g_dr:
    description: Check the neighbor priority
    nodes: [ x1 ]
    show:
      frr: ip ospf neighbor {{ hostvars.dut.ospf.router_id }} json
    valid: |
      default["{{ hostvars.dut.ospf.router_id }}"][0].nbrPriority == 200

This works only for frr, and provides the command to use to get OSPF state information. Instead, we would have a data model that says there are OSPF neighbors and each has a 'priority' attribute. The validation would state that ospf_neighbor[ id ].priority == 200, and Netlab would figure out that on FRR, it would have to run " ip ospf neighbor {{ hostvars.dut.ospf.router_id }} json" and get the nbrPriority field. On EOS it would be something different

[sdargoeuves]

I guess using a tool like SuzieQ could help? I'm not too familiar with it, but with another tool kind of similar, where you can access a vendor neutral state of your network, in snapshots.
You could then find all ospf neighbours priority in one place.

[ddutt]

Hi Seb, Maybe. Why can't we use the netlab validation testing as a basis instead. Furthermore, as Ivan said, given that there are other open source discovery tools out there, translating to a single internally consistent model to netlab might be simpler/faster. Dinesh

…

On Thu, Jan 9, 2025 at 10:57 AM Seb ***@***.***> wrote: I guess using a tool like SuzieQ could help? I'm not too familiar with it, but with another tool kind of similar, where you can access a vendor neutral state of your network, in snapshots. You could then find all ospf neighbours priority in one place. — Reply to this email directly, view it on GitHub <#1789 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGIXE2WZ5ROZM3T2WZODQL2J3BCXAVCNFSM6AAAAABU3T3UQGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOBRGA2DCMJQHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ipspace]

That's my point: Netlab has an abstraction layer for the configuration model, but not for the state model. Users are left to figure out which show commands to use, and how to parse the output.

Ah, I was pulled too quickly into the "reverse engineer a running network" bit of your idea.

What's missing in my view, is a data model for the state. Once we have that, it would also be used for validation

So you plan to reinvent IETF SNMP MIBs or OpenConfig? The industry has tried to implement this idea for the last 35 years and failed consistently. For another data point, the NAPALM team has been working on this for at least a decade, and this is how far they got: https://napalm.readthedocs.io/en/latest/support/index.html#getters-support-matrix

But hey, I have nothing against someone writing a validation plugin that uses either SNMP or whatever the latest fad replacing it is.

This works only for frr, and provides the command to use to get OSPF state information. Instead, we would have a data model that says there are OSPF neighbors and each has a 'priority' attribute.

Gee, there's already a model for that: https://github.com/openconfig/public/blob/master/release/models/ospf/openconfig-ospfv2-area-interface.yang#L274

Or two: https://datatracker.ietf.org/doc/html/rfc9129#name-ospf-interface-configuratio (ouch, they forgot about neighbor DR priority in this one)

Or three: https://datatracker.ietf.org/doc/html/rfc4750#section-2.1.7

I just wanted to get the job done, and I only plan to use FRR as the probe in the integration test ;)

[ipspace]

I guess using a tool like SuzieQ could help?

Netlab validation tests can already use SuzieQ: https://netlab.tools/topology/validate/#lab-validation-with-suzieq

I'm not too familiar with it, but with another tool kind of similar, where you can access a vendor neutral state of your network, in snapshots.

The snapshots might be good enough for what @steffann has in mind but even there, the students would have to wait for the tool to take a snapshot before running the "am I done?" test. They are not OK for integration tests that have to be done ASAP (because I hate waiting for a week to get them done if I can only wait for 48 hours 😜)