Similar to Peter, I don't fully understand your scenario.
10.10.10.10/SID 1 is originated by RT1
10.10.10.10/SID 3 os originated by RT3
Now you change SID config on RT1 so it advertises:
In a short period of time RT2 should also reflect this update.
So the statement "SID:1 is forever in LSDB" makes no sense to me.
Certainly there is a transient period during which databases may have different
combinations of (1,3) or (4,3) or even (1,3,4) but this will not persist.
From: Mahendra Singh Negi [mailto:mahendrasi...@huawei.com]
Sent: Thursday, February 22, 2018 8:49 PM
If you please provide your inputs on the issue.
Amidst implementing conflict resolution for OSPF SR (
https://tools.ietf.org/html/draft-ietf-spring-conflict-resolution-05) we came
across this issue.
1. Prefix conflict occurs at RT1 and RT2.
2. Both RT1 and RT2 resolve the conflict and download corresponding Label
for SID:1 (SID:1 wins conflict resolution).
3. Both RT1 and RT2 advertise inter-area Extended Prefix Opaque LSA for
prefix 10.10.10.10 in area a1 with SID:1.
(If an OSPF router advertises multiple Prefix-SIDs for the same prefix,
topology and algorithm, all of them MUST be ignored.)
4. Now at RT1, user changes the SID configuration value to 4, and still
SID 1 wins the conflict resolution as in area a1 RT2 has not flushed or updated
SID:1, and SID:1 is forever in LSDB.
How to fix the issue?
a) think ABRs should advertise all the SIDs to leaking areas and MUST
condition mentioned highlighted in yellow above be relaxed (i.e. update
inter-area segment routing section accordingly) and let each node run
b) On SID configuration change, RT1 Flushes the SID:1 and waits for SID:1
flushing out from the LSDB and then originates with new SID:4.(How long to wait
is decided locally).
I prefer (a), if you please provide your opinion on this. We are under
development, highly appreciate prompt responses.
OSPF mailing list