Peter, So the answer to my original question/observation and Joel’s is ‘yes, you may want/need multiple OFA’s in order to support the optimization objectives of the FA traffic your offloading’
Thnx, —Colby From: Peter Psenak <[email protected]> Date: Friday, July 17, 2026 at 11:23 AM To: Joel Halpern <[email protected]>; Colby Barth <[email protected]>; lsr <[email protected]>; [email protected] <[email protected]> Subject: Re: [rtgwg] Re: [Lsr] Comments on draft-psenak-lsr-igp-dcm-00 Joel, please see inline (##PP): On 17/07/2026 16:22, Joel Halpern wrote: One question on one of your comments... On 7/17/2026 10:00 AM, Peter Psenak wrote: ... * * Further, if flex-algo is already in use, do you also need per flex-algo OFA topologies so as to maintain the optimization objective for the flex-algo topology you’re off-loading from? ##PP depends, you can share the same OFA for multiple FAs, or you can have unique OFA for each of them. It is not always required to offload the traffic for all algos - e.g. offloading the best effort traffic only may be sufficient in many cases. I am not sure I read this properly. It looks like you are saying that you only need as many OFP flex-algos as the number of flex-algos needed to relieve the congestion. ##PP no, what I'm saying is that you do not need to use DCM for all algos. If you have an algo-0 best-effort traffic, which tends to be bursty and that represents 80% of your traffic, and 20% of the FA specific traffic which is a low latency traffic, you may decide to use DCM for algo-0 traffic only. If the link becomes congested, you only offload the best effort traffic. thanks, Peter During congestion remediation, that seems to be the case. But I think the flex-algos need to be defined at configuration time and consume router resources at all times, not just when you decide to remediate congestion. So the fact that a given event may only need 1 extra does not remediate the need for N+1 extra when vvbest effort plus n flex-algos are already in use. Have I read this properly? Yours, Joel(for full disclosure, working for HPE)
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
