Hi Ketan, > KT2> I see the primary use case for IP FlexAlgo (or another data plane) > > to be that the data plane is used by itself. In the (rare?) case where > > multiple data planes are required to coexist, it is simpler both from > > implementation and deployment POV to use different algos. It would be > > good to have operator inputs here. The only cost that I see for this is > > that the same FAD may get advertised twice only in the case where it is > > identical for multiple data planes. So I am still not seeing the benefit > > of enabling multiple (i.e. per data plane) computations for a single > > algo rather than just keeping it a single computation per algo where a > > single data plane is associated with a specific algo. > > ##PP3 > I really do not see the problem. As you stated above repeating the same > FAD for multiple algos would be inefficient. The beauty of FAD is that > it is app independent and can be used by many of them. >
As I had very same doubts as you I think the advantage here is that even for the same FAD you can have different links attribute/metric values advertised on a per "app" basis. Hence you may effectively get different topologies on a per "application" basis while still using same algorithm. Again as I and others said it few times the name "app" is badly chosen to describe forwarding behaviour in data plane but I guess no one is going to listen and change that name now :) Practically if folks will use different algorithms to construct different topologies or use the same algorithm with different metrics all depends on what real user _applications_ the network is to carry modulo what flexibility network elements used to construct such network provide. Thx, R.
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
