On Thu, Dec 12, 2024 at 05:34:36PM +0100, Dumitru Ceara wrote:
> On 12/12/24 3:02 PM, [email protected] wrote:
> >>>>>>
> >>>>>>> + "logical_port": {"type": {"key":
> >>>>>>> {"type":
> >>>>>>> "uuid",
> >>>>>>> +
> >>>>>>> "refTable":
> >>>>>>> "Port_Binding",
> >>>>>>> +
> >>>>>>> "refType":
> >>>>>>> "strong"}}},
> >>>>>>> + "ip_prefix": {"type": "string"},
> >>>>>>> + "tracked_port": {"type": {"key":
> >>>>>>> {"type":
> >>>>>>> "uuid",
> >>>>>>> +
> >>>>>>> "refTable":
> >>>>>>> "Port_Binding",
> >>>>>>> +
> >>>>>>> "refType":
> >>>>>>> "strong"},
> >>>>>> Given that tracked_port is optional, wouldn't it be better
> >>>>>> for
> >>>>>> this
> >>>>>> reference to be weak? Otherwise we run into the same issue
> >>>>>> of
> >>>>>> needing
> >>>>>> manual northd logic when removing Port_Binding referenced
> >>>>>> here.
> >>>>> The goal for the tracked_port is to specify the "nexthop"
> >>>>> Port_Binding
> >>>>> of a Route. If the Port_Binding would be removed then this
> >>>>> Route
> >>>>> is no
> >>>>> longer valid and needs to be removed anyway. So i think
> >>>>> because
> >>>>> this is
> >>>>> directly related we don't need to be weak.
> >>>>>
> >>>> I agree.
> >>>>
> >> I guess I misunderstood the docs for the "tracked_port", I thought
> >> that
> >> it would be optional even for the host routes. Is the intention
> >> that
> >> multiple chassis would advertise the same host route with different
> >> metrics based on this column?
> > Yes, at least for our usecase that would be the goal.
> > It allows us to always have backup paths already installed in the
> > network.
> > Also during the ovs/ovncon i had talks with multiple people that
> > would
> > want to do something similar.
> >
> > Theoretically we could then also use tracked_port for non-host routes
> > if
> > the nexthop is bound to a specific chassis. E.g. if you have a static
> > route pointing to a VM LSP (maybe a VPN gateway or so). Then the
> > fabric
> > might also be able to steer traffic better.
> >
>
> Hmm, on this note. Shouldn't tracked_port be part of the index then?
> Otherwise we can't have multiple chassis advertising the same host route
> with different "tracked_port" values.
Hi Dumitru,
i did not think of it, but yes that makes sense.
>
> Would this be ok as an incremental change?
Looks good for me.
Should i send a v5 with this, or do you change it when applying the
patch?
Thanks a lot
Felix
>
> diff --git a/ovn-sb.ovsschema b/ovn-sb.ovsschema
> index 61bc264579..3056ecc389 100644
> --- a/ovn-sb.ovsschema
> +++ b/ovn-sb.ovsschema
> @@ -1,7 +1,7 @@
> {
> "name": "OVN_Southbound",
> "version": "20.38.0",
> - "cksum": "2175279464 33450",
> + "cksum": "3113335473 33491",
> "tables": {
> "SB_Global": {
> "columns": {
> @@ -635,7 +635,8 @@
> "external_ids": {
> "type": {"key": "string", "value": "string",
> "min": 0, "max": "unlimited"}}},
> - "indexes": [["datapath", "logical_port", "ip_prefix"]],
> + "indexes": [["datapath", "logical_port",
> + "ip_prefix", "tracked_port"]],
> "isRoot": true},
> "Learned_Route": {
> "columns": {
>
> Thanks,
> Dumitru
>
>
>
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
