IETF seems to be doing great job in defining protocols and their extensions. It doesn't do that great job in defining the dynamics of protocols and their recommended behavior. That's called a "vendor's secret sauce".
This thread seems to be a good example of that. In BGP there was similar discussions on number of timers which BIPs (best implementation practices) are well known to limited circle of folks. Sometimes instead of such timers different safety checks are implemented under the hood. Take BGP MRAI as example ... some implementations do it one way some completely other and claim our MRAI is 0. But when asked "Do you always generate bgp update immediately" -- you hear "Oh NO !" Draft written by Paul to make it easy to implement for those from outside the circle did not go far in spite of becoming IDR WG doc: https://tools.ietf.org/html/draft-ietf-idr-mrai-dep-04 Here we have a proposal to replace part of that sauce with TCP and maybe QUIC in a backwards compatible fashion to allow for more food diversity. Yes it is a burden for existing chefs to now have to handle one more in/out channel, but let's realize that if we keep status quo alternative solutions to running IGPs may be winning more markets ... Kind regards, Robert. On Mon, Nov 12, 2018 at 6:48 PM <[email protected]> wrote: > > Les, > > As you’ve said in person, following the LSP transmission and > re-transmission timer requirements is one of the first things to go. > > Yes, updating the RFC with all of the other learnings would be one way > forward. > > Tony > > > > On Nov 12, 2018, at 9:44 AM, Les Ginsberg (ginsberg) <[email protected]> > wrote: > > > > Tony - > > > > AFAIK no one has suggested or is planning to update/modify a standard. > > > > This falls into a category of standard deviations that was initially > documented in https://tools.ietf.org/html/rfc3719 . > > If the WG feels this is important enough perhaps the best thing to do is > update that RFC. > > > > I would however like us to agree that the subject of this thread is > inappropriate. :-) > > > > Les > > > > > >> -----Original Message----- > >> From: Tony Li <[email protected]> On Behalf Of [email protected] > >> Sent: Monday, November 12, 2018 9:14 AM > >> To: Les Ginsberg (ginsberg) <[email protected]> > >> Cc: Henk Smit <[email protected]>; [email protected] > >> Subject: Re: Teasing us with secrets > >> > >> > >> Les, > >> > >>> Discussion of bypassing the ISO 10589 flooding pacing timer was done in > >> public many years ago when sub-second convergence was introduced. > >>> Here is one public paper: > >>> > >>> https://inl.info.ucl.ac.be/publications/achieving-sub-second-igp- > >> convergence-.html > >>> > >>> There are also multiple vendor specific configuration guides which > discuss > >> tuning LSP pacing for fast convergence - please consult your favorite > vendor's > >> documentation links (not my place to share such links). > >>> > >>> No doubt others can find other public references. > >> > >> > >> Thank you for the reference, that’s helpful. > >> > >> Are you aware of the standards status of this document vs ISO 10589? > >> > >> It seems to me that unless there’s some document on the standards track > >> that the average developer might not comply with it. > >> > >> Tony > > > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
