On Mon, Dec 16, 2024 at 10:42:55AM +0100, Dumitru Ceara wrote:
> On 12/16/24 10:41 AM, Felix Huettner wrote:
> > 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?
> >
>
> No need for v5, I'll squash it in and push it soon.
Thanks a lot
>
> Thanks,
> Dumitru
>
> > 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
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
