Anton - Everyone agrees that router-id duplication is a low probability event if (as you say) implementations follow the rules about selecting a router id. Nevertheless the draft - quite correctly IMO - defines how to resolve duplication if it occurs because it is still possible. My proposal is a simple extension to the existing tie breaker rules to lessen the probability that the network need be disrupted in the event router-id duplication occurs during normal maintenance/upgrade procedures.
I have proposed no changes to the router-id selection logic and I was not motivated by the possibility of poor implementations - though I think that point only adds to the value of my proposal. (Of course one may rightly wonder if an implementation doesn't correctly implement router-id selection whether it can be expected to correctly implement tie breaking - but I think we are wandering into areas we have no control over. Buggy implementations can disrupt a network and we hope the marketplace eventually resolves that issue by not buying such products.) Les > -----Original Message----- > From: Anton Smirnov (asmirnov) > Sent: Friday, February 07, 2014 5:47 AM > To: Les Ginsberg (ginsberg); Acee Lindem; Curtis Villamizar > Cc: OSPF List > Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3- > autoconfig-05.txt > > Hi Les, > if I understand correctly, all this is in addition to RID > duplication and resolution mechanisms, i.e. you do not expect that doing > *only* this will render RID duplication resolution unnecessary, right? > > If RID selection algorithm is good (i.e. statistical spread of > selected RIDs is even over the whole space) then quick math shows that a > device joining home network with, say, 1000 already connected devices > has less than 1 chance in billion to generate conflicting RID. To me > this risk looks not worth solving. > The big question of course is in statistical quality of RID > selection algorithm implementations. Since there will be many different > implementations some of them are going to be subpar. And bad > implementation may make probability of RID conflict close to 1. > Is this what you are worried about? > > Anton > > > On 02/07/2014 09:31 AM, Les Ginsberg (ginsberg) wrote: > > So, I am one person who raised this concern to Acee - but the proposal > outlined by Acee is not what I had in mind. There is no need to use "uptime" > or to invent some unusual exchange of LSAs prior to Exchange state. > > > > Also, in regards to Curtis's comment - it is not DOS attacks that I am > trying to mitigate here. As he says if an attacker is in your network and > able to originate credible packets no strategy is safe. > > > > The motivating use case is to minimize disruption of a stable network when > a new router is added or an existing router is replaced/rebooted. In other > words non-disruptive handling of the common maintenance/upgrade scenarios. > > > > What I have in mind is this: > > > > 1)A router needs a way to advertise that it has been up and running for a > minimum length of time - for the sake of discussion let's say 20 minutes. > Routers then fall into two categories: > > > > o Old routers (up >= minimum time) > > o New routers (up < minimum time) > > > > 2)When a duplicate router-id is detected, the first tie breaker is between > old routers and new routers. The old router gets to keep its router-id and > the new router picks a new router-id. > > If both routers are "new" or both routers are "old" then we revert to the > existing tie breakers defined in the document (link local address for > directly connected routers and fingerprint info for non-neighbors). > > > > 3)Advertisement of the "old/new" state requires a single bit - but it has > to be available both in hellos and the new AC-LSA. Adding it to the AC-LSA is > easy to do. For hellos, there are two possibilities: > > > > o Use one of the Options Bits > > o Use LLS > > > > Be interested in how folks feel about this. > > > > Les > > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
