Olla Krisztian, Thanks for taking the time.
On Sun, 2006-29-01 at 22:54 +0100, KOVACS Krisztian wrote: > Hi, > > On Saturday 28 January 2006 13:45, jamal wrote: [..] > I don't really like the idea of generating events unless explicitly > requested by the KM. Once a PF_KEY interface is in place such behaviour > mightl break compatibility with racoon's libipsec which considers unknown > extension headers as errors. > > > Whether or not a PF_KEY interface for these events is desired is also a > good question. Initially I had a patch for PF_KEY, but only because we > used racoon and it was easier to implement a pfkey extension than adding > netlink support to racoon. Such PF_KEY extensions would just add even > more types to the growing list of non-standard PF_KEY extension headers. > > To put it simple: I don't think PF_KEY is worth the hassle unless > someone comes up with an open source software utilizing that interface. > I agree. And if you look at something like sasyncd, it is obvious you dont need it if what you want to achieve is failover. Infact you dont need racoon in some cases at all (example this could be done for manual setup as well). In the case you do use racoon, the question is ISAKMP SAs; how do you fail those over? i.e how do you keep racoon-master and racoon-slave synced - one idea could be to make sure the cookies are synced. I know in your work you were doing something with racoon - was there anything of this sort that you did? [..] > > > > How expensive are timers these days? Lets handwave a moderately large > > number of SAs (100K). With this we would have 200K timers as opposed to > > 100K if we aggregated them. > > Of course we could aggregate these timers, this is just a leftover from > the very first patch. However, this would mean that a more fine-grained > timing would be necessary for that timer instead of the current > precision of one second. I thought about this after i typed my last email. The more fine grained the timer, the better the failover time. The SA expiry timers dont need anything more than 1 sec granularity (infact anything lower than 60 seconds will be considered strange) > Which is of course not a problem, just makes the patch a bit more intrusive. > true although i am still curious if it may be worth the complexity of having a single timer - the only reason i can see for aggregation is for perfomance reasons. > > Waking up when nothing is happening is OK, but waking up and generating > > events when nothing is happening is not. so the rescheduling is fine as > > far as i can see but what you describe is an optimization i.e > > knowing nothing has happened and never waking up is even better. > > Krisztian? > > Sure, pretty good point. > Ok, I will fix this. > One more thing: whether or not this timer is necessary really depends on > how the sync daemon uses these events. The most simple trick of simply > adding a large-enough constant to the sequence numbers of outgoing > packets after failover does not take advantage of this feature. Of course > if someone comes up with a more exact way of handling failover cases, > then those additional update messages could be useful. The timer allows for more exact values. IOW, if you use the timer and you dont loose any events you can _guarantee_ exact numbers; with padding the replay it becomes: a) if you make it small more of how lucky you are in choosing a good padding or b) dropping a substantial amount of packets if you use brute force and make it large. The trick of padding the replay values on the backup node could still be used in addition to the timer but only a small padding is needed. In any case, this mechanism is still needed/valuable. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
