Hi, On Sat, Mar 24, 2018 at 6:57 AM, Robert Raszuk <[email protected]> wrote: > Dear Authors, > > Let me just ask one little question .... > > It seems that ISIS protocol already meets a "Link State Over Ethernet" > definition so why to invent anything new here ?
My thought also. > If you don't like flooding properties of ISIS just disable it. Do not flood. > Do not run SPF in ISIS.. Use ISIS only for p2p discovery. IS-IS now explicitly supports link-scoped "flooding" as per RFC 7356 "IS-IS Flooding Scope Link State PDUs (LSPs)". It also support 16-bit TLV lengths. See in particular Extended Level 1 Circuit Scope (E-L1CS) in RFC 7356. > You get for free out of the box all what you are trying to describe in the > subject document. Integrating open source ISIS code just for discovery (ie. > not worring about optimizations of flooding, back-off, timers, spf etc ...) > will be IMO much faster even using any apache license existing > implementation of ISIS. And authentication (RFC 5310). Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA [email protected] > Last - as Toerless already indicated - solving inevitable inconsistencies of > running LSOE, CDP & LLDP between various devices or in parallel on the same > links is something that should be addressed from day one. Unless you assume > that if someone is to use LSVR is will also have LSOE and any other > alternative discovery mechanisms will be disabled. > > Best, > RR. > > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
