I’d suggest that the IGP is still not a dump truck. Putting labels on the side of it doesn’t make the situation better.
I’m opposed to this work. Tony > On Nov 10, 2022, at 3:07 AM, Aijun Wang <[email protected]> wrote: > > Agree. > > It is simple to put different application information onto different planes, > but it brings the complex for operator to manage such planes, and the inter > communication among different planes. > > Lacks of deployments for Geninfo in IS-IS can also predict the future fate of > such approaches in some sense. > > > Aijun Wang > China Telecom > >> On Nov 10, 2022, at 10:48, Robert Raszuk <[email protected]> wrote: >> >> >> Thx Acee ... >> >> Since you mentioned "sparse" and since you highlighted that OSPF is better >> then ISIS for this as it runs over IP I took a risk if not using flooding is >> an option. >> >> Well ... apparently not. >> >> Of course you could build lots of parallel GT planes and still flood in each >> across interested parties for a given type of info present in such a plane, >> but this comes with much more overhead then pub-sub. >> >> Cheers, >> R. >> >> >> On Thu, Nov 10, 2022 at 11:34 AM Acee Lindem (acee) <[email protected] >> <mailto:[email protected]>> wrote: >> Hi Robert, >> >> >> >> From: Robert Raszuk <[email protected] <mailto:[email protected]>> >> Date: Wednesday, November 9, 2022 at 10:37 AM >> To: Acee Lindem <[email protected] <mailto:[email protected]>>, lsr <[email protected] >> <mailto:[email protected]>> >> Subject: OSPF-GT >> >> >> >> Hi Acee, >> >> >> >> The point of sparse GT makes it much more attractive. >> >> >> >> With that I have two questions/suggestions to make it even more useful. >> >> >> >> #1 Would you consider adding reflection function to spares mode GT ? >> >> >> >> Within a flooding scope (e.g., area) , reflection is inherent in the >> flooding algorithm. One thing that applications will need to specify is >> whether or not information is re-originated outside the flooding scope >> (e.g., does the ABR re-originate application LSAs into other areas). >> >> >> >> >> >> #2 If you do #1 would you considet pub-sub model ? >> >> >> >> I wouldn’t change basic OSPF flooding. So, one could support pub-sub but >> everyone in the OSPF application routing domain would receive a superset of >> subscribed information (or the application would have to do something >> unnatural from an OSPF standpoint to limit the neighbors receiving the >> information, e.g., dynamically assign areas for unique subscriptions). I >> think other protocols are better suited to pub-sub. >> >> >> >> Thanks, >> Acee >> >> >> >> Then this could be used for lot's of current use cases ... some of them even >> discussed today :) >> >> >> >> Thx >> >> R >> >> _______________________________________________ >> Lsr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
