search

ietf-wg-cats / CATS-framework

Other
1 stars 4 forks source link

About several C-PS computation logics in the network #22

Closed Deguello1 closed 10 months ago

Deguello1 commented 1 year ago

The C-SMA then advertises the CS-IDs along with the metrics to be received by all C-PSs in the network

This encourages some clarification about the respective roles and responsibilities of all the C-PSes deployed in the network. let alone the security and consistency issues that may arise because of such design. This should deserve an editor's note at least.

VMatrix1900 commented 11 months ago

It is not necessary to propagate the metric to all C-PS. This IDR draft by CMCC proposes notification domain to segment C-PSs. If there will not be clients connected through an ingress, then there is no need to advertise the CS-ID and metric to it.

muzixing commented 11 months ago

I think we may need to modify the text here. First of all, the C-SMA should advertise the CS-ID to the egress CATS-Forwarder which is connected to the site? and then the Egress CATS-Forwarder will redistribute the metrics with other network metrics together to related Ingress CATS Forwarder?

Depending on the deployment, all/part of service metrics may be collected by a central controller ort central entity, and then send to the Ingress CATS forwader. is it correct?

Therefore, I propose the update as below,

OLD The C-SMA then advertises the CS-IDs along with the metrics to be received by all C-PSes in the network.

NEW

The C-SMA then advertises the CS-IDs along with the metrics to related C-PSes in the network. Depending on the deployment choice, the CS-IDs among with the metrics may be distributed to an Egress CATS Forwader firstly and then be redistributed by the Egress CATS Forwarder to related C-PSes, or they may be collected by a central entity and then be distributed to the related C-PSes.

What do you think?

VMatrix1900 commented 11 months ago

The first step is not necessary either. The metric can be collected by a centralized C-SMA(say cloud management) and distributed directly to the ingress, bypassing the egress.

muzixing commented 11 months ago

We may have multiple types of deployment. In one deployment, the C-SMA can built the connections with the ingress CATS Forwarder, so it can send the mertics directly.

But in other use cases/deployments, the C-SMA might do not have the right to build the connection with ingress CATS-Forwarder. It miht only have a control plane connection with the attached Egress CATS-forwarder, so the only way is to send the route/CS-ID with the metrics to the egress CATS-Forwarder. Then the Egress CATS-Forwarder will do the rest. Especially in VPN scenarios, the original instance route will only be sent to the Egress CATS-Forwarder/PE, and the Egress CATS-Forwarder will redistribute the route/CS-ID with metric in VPN route style.

Therefore, I think it is valid to describe these two ways.

muzixing commented 11 months ago

Hi Med, any feedback of my reply？If you agree, we can merge it into this updat, if not, we can continue the discussion, and address it in the future. Same to other issues that I have replied to you.

boucadair commented 11 months ago

@muzixing, please propose the text as a PR. Will act on it :-)

muzixing commented 10 months ago

will do. But I am planning to post a new revision(current text) this week. We can address this in the next revision. so no need to be rush.

muzixing commented 10 months ago

@Deguello1 please review the PR to see if it is ok to you https://github.com/boucadair/CATS-framework/pull/54/commits/1aebab3b00f29a0a131f25a410bb5881b7839af3