>>> We do actually update the garbage collection time regardless of the
>>> route metric in the regular update function (but not when sending an
>>> explicit retraction). I think that's OK, though?
>> Does that mean that a retracted route never expires?
> Hmm, no, this is the garbage collection
Juliusz Chroboczek writes:
>> This has been clarified in RFC8966 as: "Note that the feasibility
>> distance is not updated and the garbage-collection timer is not reset
>> when a retraction (an update with infinite metric) is sent."
>>
>> The feasibility distance is only updated if the metric
> This has been clarified in RFC8966 as: "Note that the feasibility
> distance is not updated and the garbage-collection timer is not reset
> when a retraction (an update with infinite metric) is sent."
>
> The feasibility distance is only updated if the metric is lower, which
> is never true for
Ondrej Zajicek writes:
> On Tue, Jan 31, 2023 at 11:55:50AM +0100, Toke Høiland-Jørgensen via
> Bird-users wrote:
>> When creating a new babel_source object we initialise the seqno to 0. The
>> caller will update the source object with the right metric and seqno value,
>> for both newly created
On Tue, Jan 31, 2023 at 11:55:50AM +0100, Toke Høiland-Jørgensen via Bird-users
wrote:
> When creating a new babel_source object we initialise the seqno to 0. The
> caller will update the source object with the right metric and seqno value,
> for both newly created and old source objects. However
When creating a new babel_source object we initialise the seqno to 0. The
caller will update the source object with the right metric and seqno value,
for both newly created and old source objects. However if we initialise the
source object seqno to 0 that may actually turn out to be a valid
