Re: [Teas] Mail regarding draft-ietf-idr-flowspec-network-slice-ts

"Dongjie (Jimmy)" <jie.dong@huawei.com> Tue, 18 April 2023 15:53 UTC

Return-Path: <jie.dong@huawei.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850C9C15154D; Tue, 18 Apr 2023 08:53:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 lQJ7tXnsTKg2; Tue, 18 Apr 2023 08:53:22 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EB0DC151540; Tue, 18 Apr 2023 08:53:22 -0700 (PDT)
Received: from lhrpeml500005.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Q17cl2s2Vz6D8X5; Tue, 18 Apr 2023 23:48:39 +0800 (CST)
Received: from kwepemi100015.china.huawei.com (7.221.188.125) by lhrpeml500005.china.huawei.com (7.191.163.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Tue, 18 Apr 2023 16:53:18 +0100
Received: from kwepemi500017.china.huawei.com (7.221.188.110) by kwepemi100015.china.huawei.com (7.221.188.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Tue, 18 Apr 2023 23:53:16 +0800
Received: from kwepemi500017.china.huawei.com ([7.221.188.110]) by kwepemi500017.china.huawei.com ([7.221.188.110]) with mapi id 15.01.2507.023; Tue, 18 Apr 2023 23:53:16 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "draft-ietf-idr-flowspec-network-slice-ts@ietf.org" <draft-ietf-idr-flowspec-network-slice-ts@ietf.org>
CC: "TEAS WG (teas@ietf.org)" <teas@ietf.org>
Thread-Topic: Mail regarding draft-ietf-idr-flowspec-network-slice-ts
Thread-Index: Adlx5Nnx/SuQ89w/T1Knqu3aF0GmCQAJIKlQ
Date: Tue, 18 Apr 2023 15:53:16 +0000
Message-ID: <be964c4360a946b9b91c6dfab9d0c8bb@huawei.com>
References: <37169_1681818442_643E834A_37169_198_1_PAVPR02MB967381FD2369536168765561889D9@PAVPR02MB9673.eurprd02.prod.outlook.com>
In-Reply-To: <37169_1681818442_643E834A_37169_198_1_PAVPR02MB967381FD2369536168765561889D9@PAVPR02MB9673.eurprd02.prod.outlook.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.48.135.141]
Content-Type: multipart/alternative; boundary="_000_be964c4360a946b9b91c6dfab9d0c8bbhuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/-csdZ-aC253ZcmQPAaRPvCN1s5U>
Subject: Re: [Teas] Mail regarding draft-ietf-idr-flowspec-network-slice-ts
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Apr 2023 15:53:24 -0000

Hi Med,

Thanks for your review and comments on this document. You may misunderstand the mechanisms described in this draft a little, so let me try to clarify.


The purpose of the proposed mechanism is to use BGP Flowspec to distribute the rules for matching some fields of the network slice service packets at the network ingress nodes, then the matched packets could be steered into the corresponding NRP.  Thus it is about steering network slice services into NRPs, and optionally specific TE paths of the NRPs. It does not infer any limitation about whether multiple network slices services are mapped to the same or different NRPs. As you said that is all based on deployment policy.



As mentioned in the draft, the existing Flowspec components can be reused for the matching of network slice services at the edge of an NRP, so the matching is not just based on the NRP ID. Actually the NRP ID component is only introduced for some specific cases (e.g. the domain edge nodes of multi-domain NRPs) for packet matching. We will clarify that in next revision.


Best regards,
Jie

From: mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>
Sent: Tuesday, April 18, 2023 1:47 PM
To: draft-ietf-idr-flowspec-network-slice-ts@ietf.org
Cc: TEAS WG (teas@ietf.org) <teas@ietf.org>
Subject: Mail regarding draft-ietf-idr-flowspec-network-slice-ts

Hi Authors,

The proposal in the draft is not actually about slice steering, but NRP steering. An NRP can be shared between multiple connectivity constructs of the same or distinct slices. Likewise, there is no assumption that all CCs of a slice will be mapped to the same NRP. Also, when the same NRP is used for more than one slice, distinct forwarding paths (and thus distinct actions) may be selected for each slice that shares the NRP. The NRP-ID alone is not sufficient to disambiguate slice traffic. Whether an NRP maps to one and only one slice is deployment-specific.

I think the current text in the draft is misleading. I suggest you revise the draft to better articulate the intent and capture the differences between the concept of slice vs. nrp. Thanks.

BTW, how the global bit is used?

Thanks.

Cheers,
Med

_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.