> We don't need consistency between different AS/providers. > We need consistency within a given AS, across vendors.
Correct -- but a BCP isn't just for inter-AS, it's also for intervendor. > BCP for existing _parameters_ do not solve the problem if we have different > algorithm computing different values. > What we need is to standardize an algorithm. Is your point is that such > document should be labeled as "IETF BCP" rather than "IETF standard track"? > If so, I would tend to disagree as IMO this is required for interop. The problem is with the word "interop." Typically, algorithms have only been specified to the point that all instances of a given routing protocol are eventually consistent (how the best path is calculated, which events should or should not trigger updates, etc.) -- what you're asking is for this to be extended to timing and the actual process used in specific situations. This would analogous to asking for a spec around the actual way in which BGP tables are stored (rather than the theoretical model proposed in the BGP specs). I see a couple of problems with going down this path -- the most prominent of which is that it kills off the ability to think of better ways to implement the functionality under discussion. Given all of this, the problem we have is that different implementations back off in different ways, which causes microloops and microblackholes. If we set upper and lower bounds on the time to react in each given situation, then we're solving that problem without telling people how to get to those upper and lower bounds. If we propose an actual algorithm, then we're telling people not only what must happen, but how it must happen. I suspect we're crossing a line in there someplace that reaches outside the IETF's scope. Hence, I would argue for a BCP that says, "this is what must happen and when," which would be similar to telling BGP implementors the way dampening should look from another implementation's point of view... The implementation is still (pretty much) a block box. I don't know if we should slip over the line into telling people how to implement. I'm willing to be persuaded, I just don't see the argument for specifying an algorithm with what's been put on the table to this point. :-) Russ _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
