Re: [Lsr] Teasing us with secrets

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 <tony.li@tony.li> 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) <ginsberg@cisco.com>
> 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 <tony1athome@gmail.com> On Behalf Of tony.li@tony.li
> >> Sent: Monday, November 12, 2018 9:14 AM
> >> To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>
> >> Cc: Henk Smit <hhwsmit@xs4all.nl>; lsr@ietf.org
> >> 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
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>