[OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.txt

[Acee Lindem <[e-mail]>]

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