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 <rob...@raszuk.net> 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) <a...@cisco.com> wrote: >> Hi Robert, >> >> >> >> From: Robert Raszuk <rob...@raszuk.net> >> Date: Wednesday, November 9, 2022 at 10:37 AM >> To: Acee Lindem <a...@cisco.com>, lsr <lsr@ietf.org> >> 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 > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
