Hi Curtis, I agree and believe the significance of this use case where a new router is inserted into an auto-configured domain has been greater exaggerated. Thanks, Acee On Feb 5, 2014, at 3:58 PM, Curtis Villamizar <[email protected]> wrote:
> > In message <cf17dd4e.2696b%[email protected]> > Acee Lindem writes: > >> 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 > > > Acee, > > If the basis for router-id on boot up results in a fixed value, and if > a duplicate will occur on a give network, then which of two duplicate > routers gets that value may change after one of them reboots. If > uptime is not considered, it will never change as long as one router > stays up at any given time. > > We are talking about a very low probability event (a duplicate) except > if this is a DoS attack and then either using or not using uptime > won't matter since the attacker will claim an impossibly long uptime. > > Curtis _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
