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

[Acee Lindem <[e-mail]>]

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 <[e-mail]> wrote:

> 
> In message <[e-mail]>
> 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