Hi Acee,
weighing probability of RID conflict against complexity of the
proposed method I agree it does not look attractive.
I think RID conflict avoidance can be made optional.
What if feedback to change RID is given to device before it has
joined the OSPF domain? I.e. before router established at least one FULL
adjacency it advertises in its Hellos "I am new". Neighboring devices
weigh if new RID looks conflicting or not and advise back to the new
device via unicast Hellos.
Anton
On 02/05/2014 09:21 PM, Acee Lindem wrote:
The OSPFv3 autoconfiguration draft was cloned and presented in the ISIS
WG (http://www.ietf.org/id/draft-liu-isis-auto-conf-00.txt). In the ISIS
WG, there was a concern that the resolution of a duplicate system ID did
not include the amount of time the router was operational when
determining which router would need to choose a new router ID. With
additional complexity, we could incorporate router uptime into the
resolution process. One way to do this would be to:
1. Add a Router Uptime TLV to the OSPFv3 AC-LSA. It would include
the uptime in seconds.
2. Use the Router Uptime TLV as the primary determinant in
deciding which router must choose a new OSPFv3 Router ID. Router uptimes
less than 3600 (MaxAge) seconds apart are considered equal.
3. When an OSPFv3 Hello is received with a different link-local
source address but a different router-id, unicast the OSPFv3 AC-LSA to
the neighbor so that OSPFv3 duplicate router resolution can proceed as
in the case where it is received through the normal flooding process.
This is somewhat of a hack as the we'd also need to accept OSPF Link
State Updates from a neighbor that is not in Exchange State or greater.
An alternative to #3 would be to use Link-Local Signaling (LLS) for
signaling the contents of the OSPFv3 AC-LSA. However, you'd only want to
send the Router-Uptime and Router Hardware Fingerprint when a duplicate
Router-ID is detected. This requires implementing the resolution two
ways but may be preferable since it doesn't require violating the
flooding rules.
In any case, I'd like to get other opinions as to whether this problem
is worth solving.
Thanks,
Acee
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
