On 11/03/2013 12:25, Saku Ytti wrote: > I don't believe this is generally supported by RIPE community, I don't > understand how it became RIPE-580 so fast.
I suspect on the basis of: "oh, that looks interesting". The I-D is preferable as an informational reference - the review mechanisms are quite a bit better in the IETF. btw, I'm not making a recommendation about operational best practice for either the RIPE doc or the I-D. Just that if the OP is going to consider implementing RFD, that he understands why he's doing it, the consequences of the existing RFD mechanisms + timers and that if he actually goes ahead and rolls it out, that he ought to give at least some passing consideration to the research that others have done because otherwise he will fall into the same pitfall everying tripped over some years back. I don't know if the recommendations in draft-ymbk-rfd-usable will scale out in such a way that they avoid the route oscillation problems of rfc2439 at a global scale, but at least some effort has been made to deal with these problems with hindsight, clue and a degree of practical measurement. The least that this I-D deserves is some informed analysis and comment. Nick _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
