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

Peng Liu <liupengyjy@chinamobile.com> Tue, 05 September 2023 11:16 UTC

Return-Path: <liupengyjy@chinamobile.com>
X-Original-To: cats@ietfa.amsl.com
Delivered-To: cats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66CAFC15154D for <cats@ietfa.amsl.com>; Tue, 5 Sep 2023 04:16:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.595
X-Spam-Level:
X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AldR2JQhrVIX for <cats@ietfa.amsl.com>; Tue, 5 Sep 2023 04:16:14 -0700 (PDT)
Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by ietfa.amsl.com (Postfix) with ESMTP id 97F8CC14CEED for <cats@ietf.org>; Tue, 5 Sep 2023 04:16:11 -0700 (PDT)
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from spf.mail.chinamobile.com (unknown[172.16.121.19]) by rmmx-syy-dmz-app09-12009 (RichMail) with SMTP id 2ee964f70df43a9-e1a4c; Tue, 05 Sep 2023 19:16:06 +0800 (CST)
X-RM-TRANSID: 2ee964f70df43a9-e1a4c
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from CMCC-LP (unknown[10.2.53.242]) by rmsmtp-syy-appsvr10-12010 (RichMail) with SMTP id 2eea64f70df43b4-2c3c1; Tue, 05 Sep 2023 19:16:06 +0800 (CST)
X-RM-TRANSID: 2eea64f70df43b4-2c3c1
Date: Tue, 05 Sep 2023 19:17:23 +0800
From: Peng Liu <liupengyjy@chinamobile.com>
To: "vasilenko.eduard" <vasilenko.eduard@huawei.com>
Cc: cats <cats@ietf.org>
References: <a21ae45f4f414e6ca4553b30a7dd454d@huawei.com>
X-Priority: 3
X-GUID: F35EDAC8-DED3-44C1-8286-B43729BAF150
X-Has-Attach: no
X-Mailer: Foxmail 7.2.21.453[cn]
Mime-Version: 1.0
Message-ID: <2023090519172328398828@chinamobile.com>
Content-Type: multipart/alternative; boundary="----=_001_NextPart724511115713_=----"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cats/NqNLD1ZFQIx7dJc7SbxdmzeX160>
Subject: Re: [Cats] [cats] draft-ietf-cats-usecases-requirements-00 -> traffic path enforcement type is missing
X-BeenThere: cats@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Computing-Aware Traffic Steering \(CATS\)" <cats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cats>, <mailto:cats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cats/>
List-Post: <mailto:cats@ietf.org>
List-Help: <mailto:cats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cats>, <mailto:cats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Sep 2023 11:16:16 -0000

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
 
From: Vasilenko Eduard
Date: 2023-09-05 16:05
To: cats
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
https://www.ietf.org/mailman/listinfo/cats