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.
Would this be ok as an incremental change?
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
