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
