Replying from mobile, forgive the top post... :-( I was thinking of a bcp that would say something like:
- these are the different points that matter in convergence timing - vendors are encouraged to provide timers between x and y for each of these - vendors are further encouraged to use x, y, ... As defaults - operators are cautioned that this is the set of problems they will face if these timers are not consistent - operators are encouraged to use consistent timers, rather than waiting on vendors to use a common set of defaults Would that cover what needs to be done without specifying an actual algorithm? :-) Russ On Jul 24, 2014, at 2:49 PM, <[email protected]> wrote: >>> 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
