yes, yes, draft will be published before cut-off, I know you _burn_ to read it ;-)
the originator will have at least one neighbor (and if multiple they're in sync per previous procedures) and this neighbor will see the LSP is older and flood back to the originator the older version by standard procedures before any optimization even kicks in. That insures that originator reissues newer and then normal procedures apply. In any case the fast PSNP would trigger re-origination or worst case CSNP but no, that should not be the primary mechanism. That is probably worth spelling out explicitly in the draft in fact. thanks -- tony On Mon, Oct 14, 2024 at 8:21 PM Acee Lindem <[email protected]> wrote: > Hey Tony, > > Another thing to consider as you are working on an update prior to the > Monday, Oct 21st draft cut-off. > > For OSPF, the protocol mechanisms for updating stale LSAs (e.g., after > router restart) require that the stale LSAs be flooded back to the LSA > originator. Hence, truncating this flooding path as specified will supplant > these mechanisms. > > I'm not sure if this applies to IS-IS. > > Thanks, > Acee > > > On Aug 23, 2024, at 4:21 PM, Tony Przygienda <[email protected]> > wrote: > > > > First, thanks e'one on this thread for their comments. > > > > Discussion is ongoing with the authors of the draft on feedback provided > by many operators of ISIS network large enough to be interested in the > technology as well as different flavors of feedback provided in this > thread. The next version will reflect those inputs. > > > > thanks > > > > --- tony > > > > On Fri, Aug 2, 2024 at 8:19 PM Acee Lindem <[email protected]> wrote: > > > > The subject draft was adopted as a WG document containing only the > flooding reduction algorithm (section 2). > > > > Procedures and signaling have been added to the current version allowing > concurrent operation within an IS-IS area of IS-IS routers running > different flooding reduction algorithms or no flooding reduction at all > (section 1). > > > > WG members are questioning if this extra requirement needs to be met and > included in this document. There was an extensive discussion during the > IETF 120 LSR meeting and a MeetEcho show-of-hands poll was taken - > https://notes.ietf.org/notes-ietf-120-lsr > > > > Please indicate your preference and reasoning amongst the following > options by August 17, 2024: > > > > 1) The document remains in its current form describing both the > flooding reduction algorithm signaling/procedures and the new flooding > reduction algorithm. > > 2) The flooding reduction algorithm and procedures will be split > into a separate document with its own LSR WG adoption call. > > 3) Some other resolution? > > > > Thanks, > > Yingzhen, Chris, and Acee (LSR Chairs) > > _______________________________________________ > > Lsr mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
