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,
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
