Hi Anton, I really don't think "I am new" announcement (however signaled) is really necessary. Hence, I'm not inclined to add it to this draft even as an optional mechanism. Thanks, Acee
On 2/7/14 9:17 AM, "Anton Smirnov" <[email protected]> wrote: > 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
