Saturday, 2026-02-07

opendevreviewMerged openstack/ironic master: Filter out NoMatch actions in _vif_attach_tbn  https://review.opendev.org/c/openstack/ironic/+/97456900:05
opendevreviewMerged openstack/ironic master: Update TBN config file to improve trait structure  https://review.opendev.org/c/openstack/ironic/+/97477600:05
TheJuliajrosser: oh, I guess if we had a clean path for some details to map in an ml2 plugin, might be easier to discuss in high bandwidth at some point as opposed to asynchronous on irc.00:43
*** gmaan_afk is now known as gmaan02:01
opendevreviewTakashi Kajinami proposed openstack/ironic-ui master: Remove MANIFEST.in  https://review.opendev.org/c/openstack/ironic-ui/+/97598207:44
opendevreviewTakashi Kajinami proposed openstack/networking-baremetal master: Remove MANIFEST.in  https://review.opendev.org/c/openstack/networking-baremetal/+/97598307:45
opendevreviewTakashi Kajinami proposed openstack/ironic-tempest-plugin master: Remove MANIFEST.in  https://review.opendev.org/c/openstack/ironic-tempest-plugin/+/97599007:48
TheJuliajrosser: I’m going to be in Ireland next week, but you’ve got me interested. What tuning are you curious to help enable do your deployed baremetal?14:48
jrosserTheJulia: wont mac/l2vni stuff be in the bgp/evpn routes?14:59
TheJuliaYes, they would be.15:00
jrosseryeah, so if you have a workload that is multicast heavy (like many 10's Gbps) then ingress replication will be a problem15:01
TheJuliaHow so? I mean at that point you likely don’t want to dumping that through a neutron router.15:01
jrosseras you will saturate the uplink from a leaf with N times the traffic that the mcast source generates, once for each destination vtep15:01
jrosseri don't forsee there being a neutron router in the data path15:02
jrosserfor a baremetal <> baremetal node flow of data15:02
TheJuliaHmm, true, so what would you envision?15:03
TheJuliaFor what it is worth, the metal tube’s boarding door has closed, I need to move to airplane mode soon.15:03
TheJuliaWould you have a limited number of VMs on that segment?15:04
jrosserperhaps i'm just raising the issue that ingress replication is not univerally suitable15:04
jrosserand a particular environment might very deliberately want to choose native multicast in the underlay instead (leveraging the switch ASIC hardware) to handle BUM traffic with "normal" protocols for that like PIM15:05
TheJuliaI think we’re aware of that, but for general cases it should be relatively suitable for most deployments with generalized workloads.15:06
TheJuliaBut with vxlan as well?15:06
TheJuliaI wonder if that is a possibility, or not, and ultimately what is the ASIC’s preference.15:09
jrossertoday i have a manually configured switch setup that is very much like the one in that set of patches ends up with15:09
TheJuliahjensas: ^^^ may be an interesting topic for us to discuss.15:09
TheJuliaInteresting!15:10
jrosserso a backend of vxlan/evpn and a resulting set of vlans which are presented as neutron provider networks15:10
jrosserprecisely because functionality like the new proposed stuff is missing15:10
TheJuliaHeh, okay!15:10
jrosserand that must use native multicast in the underlay rather than ingress replication because the workload requires it15:10
jrosser(think imaging sensor data at many gbps just sprayed out as rtp multicast)15:11
jrosserand we fully leverage the switch asic (arista/broadcom in this case) to make that efficient15:12
jrosserwhilst knowing we make a compromise with the potentially limited multicast routing table scalability15:12
jrosserso really i just wanted to raise that as an operator, it would be great in the future if there was a dial to enable things other than ingress replication and it doesnt get somehow fundamnetally written into the model across ironic/neutron15:13
TheJuliaThat makes sense. That is a key detail because it is a conscious and informed decision at that point, the challenge with all of this is general applicability. Definitely baked in hard to force only ingress replication. There is a neutron native bgp even model under development which will basically force it, but we’ve got a streamlined direct attach model. If you get time, checkout the later NGS patches15:15
TheJuliaYou’ll see some other options there, just for Cisco specially we’re leaning hard towards ingress replication in large part due to the differing model. The big issue is we’re trying to keep things as scalable as possible15:16
jrosserit may all turn out to be trivial in n-g-s (like a couple of extra config lines perhaps)15:19
jrossernut more complicated to figure how where the multicast groups etc come from via neutron15:19
jrosser*but15:19
TheJuliaOr, just not.15:20
TheJuliaA variation and challenge is numbering, since we can’t use the segmentation id as a root for things like intermediate interface numbering.15:21
TheJuliaSo, original variations had mcast groups as well. Just perceptions were that was also dated. Maybe… not.15:26
jrosseri think i would perhaps look at it depending on which industry you are in, rather than being dated or not (see introduction here https://www.arista.com/assets/data/pdf/Whitepapers/EVPN-Data-Center-Multi-Tenant-Multicast-Services-WP.pdf)16:28
TheJuliaSee https://review.opendev.org/c/openstack/networking-generic-switch/+/972763/5/networking_generic_switch/devices/netmiko_devices/arista.py :). Granted, we dialed it back but it could make sense.17:13
jrosserahhh that’s cool. - I’ve barely had enough brain cycles to lurk and watch the conversation about this :)19:01
jrossernext week I can check that config against something running20:19
TheJuliaHappy to peel back to that version if it would help you or extract the specific groupings for it21:26
TheJuliaanyway, I should go find power plugs21:27

Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!