> > 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.
Good. #Ref A > > > 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.) we also need consistency, between nodes in a given AS, on the delay before running the SPF. We agreed on this. cf above #Ref A > -- 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 disagree with your analogy. IMO, the BGP analogy is, within an AS, following an internal route change, to trigger BGP route re-computation at the same time across vendors. e.g. agree on the mechanism (e.g. BGP scan time vs triggered computation). (but it's still a bit different as for BGP you could use tunnels between ASBR to avoid hitting RIB inconsistencies) > 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. I disagree. cf slide 7 http://tools.ietf.org/agenda/90/slides/slides-90-rtgwg-2.pdf > Given all of this, the problem we have is that different implementations back > off in different ways, which causes microloops and microblackholes. +1 > 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. We need "close"/identical values, across all nodes, for _all_ the steps of the back-off algorithm/spec. From the first event of the set of consecutive events, up to the last events. If we have a 2 steps back-off algorithm (fast - slow) I guess setting the upper and lower bound is enough. But this assumes that we all agree on this 2 steps mechanism/algo. (while we/vendors don't today) We also need to define how we determine this set of consecutive events. And make sure we are consistent about which are those events (e.g. refresh LSA/LSP are not). > 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. Ok. So I guess my presentation/draft was not clear enough. Can we try to sync face to face during this week? Thanks, Bruno > > :-) > > Russ _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
