Hi Robert, Please check inline below with KT4.
On Wed, Apr 13, 2022 at 1:31 PM Robert Raszuk <[email protected]> wrote: > 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. > KT4> This is not possible. Please check my response (KT3) to Peter. All of FlexAlgo is a single "app" when it comes to link attributes using ASLA. So one cannot advertise different link attributes for different FlexAlgo forwarding mechanisms (i.e. SR or IP) when they are using the same algo and sharing the FAD. > Hence you may effectively get different topologies on a per "application" > basis while still using same algorithm. > KT4> We get different topologies only via separate signaling of Node Participation in a given "FlexAlgo forwarding mechanism" (I don't use the term "application" here) - i.e. SR Algo TLV and IP Algo TLV. > > 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 :) > KT4> I've suggested a proposal to clarify in my response to Peter. Unfortunately, the "application" in ASLA may be too late to change, but we have the opportunity to clarify in the base FlexAlgo as well as this spec. > > 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. > KT4> So the questions are really as follows: Q1) Why would an operator want to enable FlexAlgo with IP forwarding in a network where they can as well do SR forwarding based FlexAlgo? Q2) When both IP and SR Forwarding based FlexAlgo are sharing the same algo value, an implementation would need to perform separate computations when the node participation is different for the two forwarding mechanisms. In this case, is it still better to use the same algo or ok to use different algo values from an operational perspective (monitoring, troubleshooting, management, etc.)? Thanks, Ketan > > Thx, > R. > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
