Open luismcontreras opened 2 weeks ago
My understanding of metric in this document is all about compute domain metric, not network domain metric.
I think Luis's comment makes sense, we should consider separately when generating the L2 metrics. But will it be a L3 metric if these L2 metrics generated from different agents and domain. L2 from C-NMA is for path selection considering network domain metrics only. L2 from C-SMA is for instance selection considering compute domain metrics only. So can they be simply summed up at the Ingress(C-PS)? If not, will there be a simple derivation and generation of another value(L3 metric)?. I'm not recommending we should have a L3 abstraction, but try to understand such case. Welcome for discussion.:)
My understanding of metric in this document is all about compute domain metric, not network domain metric.
to Vincent, this document is about CATS metrics, so it will cover both network and compute domain, even if we may not define new network metrics, considering large amout of work in network metrics definition. Metrics in network domain is for the derivation of CATS metrics.
By domain I mean the source of the metric. That is to say, the metric defined in this document comes from computing side, not network side. Is that correct?
Discussion @11.20: Do we need to separate the network domain metric and computing domain metric? They should follow the same absctration principle.
With the current definition of L2 metric, the generation of such L2 metric can only be performed on an element consolidating both network and compute metrics. That is, the C-PS (or the Ingress C-Forwader), according to the current framework definition. It could be maybe more practical if we can consider L2 metrics per domain so that both C-SMA and C-NMA can generate L2 metrics per domain that later on can be consolidated in C-PS (or the Ingress C-Forwader), but avoiding the burden of transmitting all the L1 metrics up to C-PS (or the Ingress C-Forwader).