Re: [Cats] [cats] draft-ietf-cats-usecases-requirements-00 -> traffic path enforcement type is missing

It is good to have "tunnel" in the WG charter, but it would be lost/forgotten after the WG would be concluded next year.
The "tunnel" word is absent in the draft-ietf-cats-usecases-requirements that would become RFC and would stay active for decades.

If it is permitted to have header modification (NAT), then it is fine for me.
Ed/
From: Peng Liu [mailto:liupengyjy@chinamobile.com]
Sent: Tuesday, September 5, 2023 2:17 PM
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
Cc: cats <cats@ietf.org>
Subject: Re: Re: [Cats] [cats] draft-ietf-cats-usecases-requirements-00 -> traffic path enforcement type is missing

Hi, Eduard,

The WG charter is here:
>The assumed model for the CATS WG is an overlay network, where a network
>edge node makes a decision based on the metrics of interest, and then
>steers the traffic to a node that serves a service instance, for example
>using a tunnel.

As for the requirements, your suggestion could be seen as the perspective of techniques,
while it is now from the perspective of the functions that CATS needs.
Both of them works, the granularity of each req's description are better to be consistent.

Regards,
Peng
________________________________
liupengyjy@chinamobile.com<mailto:liupengyjy@chinamobile.com>

From: Vasilenko Eduard<mailto:vasilenko.eduard=40huawei.com@dmarc.ietf.org>
Date: 2023-09-05 16:05
To: cats<mailto:cats@ietf.org>
Subject: Re: [Cats] [cats] draft-ietf-cats-usecases-requirements-00 -> traffic path enforcement type is missing
Hi all,
Let's assume that the decision has been made and some traffic/session has been decided to push to service instance X.
How?
It is MANDATORY to avoid states on the transit router hops. It is probably what you mean in requirement R13 (I am not sure because of general "node" terminology, "source node" for sure MUST keep all states).
We have potentially 2 choices:
1. Packet header modifications (like NAT, or to be more precise "like Load Balancer").
2. Establish a tunnel (SRv6, SR-MPLS, VxLAN, whatever). Then only the ingress router would keep states.

Of course, it is possible to be silent about this problem, and let all other WGs decide themselves on their way of implementation.
IMHO: it is better to state clearly that header modification is not an option.

By the way, we are talking here about Quadrillions (or Quintillions?) of additional tunnels on a global scale.
It is evident that only "Source Routing" (SRv6 or SR-MPLS) is capable of handling it because only SR is encoding the path in the packet itself.
Refreshment of huge tables through the control plane is not an option.
Maybe it is better to mention it too.

Best Regards
Eduard Vasilenko
Senior Architect
Network Algorithm Laboratory
Tel: +7(985) 910-1105

--
Cats mailing list
Cats@ietf.org<mailto:Cats@ietf.org>
https://www.ietf.org/mailman/listinfo/cats