On 12/16/24 10:47 AM, Felix Huettner wrote:
> 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
> 

Applied to main.

Regards,
Dumitru

_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to