Re: [Teas] Applicability of IETF network slices in the 3GPP context

Shunsuke Homma <s.homma0718@gmail.com> Wed, 08 June 2022 01:24 UTC

Return-Path: <s.homma0718@gmail.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 85FAAC157B39; Tue, 7 Jun 2022 18:24:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.754
X-Spam-Level:
X-Spam-Status: No, score=-1.754 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 haqISpb367TC; Tue, 7 Jun 2022 18:24:46 -0700 (PDT)
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B4A6C157B58; Tue, 7 Jun 2022 18:24:46 -0700 (PDT)
Received: by mail-lj1-x22d.google.com with SMTP id l18so13775485lje.13; Tue, 07 Jun 2022 18:24:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Z8lvHj8ewD5VAa7ZyX9cLn67ELeViaRsQZcgEiNsg3Q=; b=e1oHv97Wqr21QuXnDf52zjqDlSGoMAkinx4dcrrfG3hPozwpReYgHc2sekt+el3sbt bcOIBuNEm71maB1Zf/5NylDW5peAH7NOxue0Fxfv26anSmyzAhSMCJrPwRExRnfbAb0t 2dB/ZBHh21fcwxH4jvyy5Z5aiMqfuW2RyIODU0Qq6ymNZpl7qOwHy1HGEn/fRnxQgu7J idco+mVh19ykSqyiFmbBTSNox0BReNf0y8kNY/leUs9u1bTrUXF4JjBSa91Oa+5fCe/D kcv+BiosGsPEopemyRZqf7Ue+8tT7JkDJQzuUyXSmMkkayYiR+N16EeFUHPDs8tbG2ay MAkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Z8lvHj8ewD5VAa7ZyX9cLn67ELeViaRsQZcgEiNsg3Q=; b=WNbu3GNhtx6ZCDLW1KnSVtkS3sVwH56EKo5ENyc7ATbY5d6W+cZ/NU0B82rXfgf031 ukw4g1QVFfp8obFtCck2bGFmoxPpLyY9yvjx8loCUAYCDfpha5Q8mFsQP5ZrEK0dIcw4 TdE/l4WCdwu2NNNpgBp35GLVTLz0aVqV/qKSD3EWiEa39XJmDOhf8OZZywzw9IDEXnzi ciGMdOTAIhfII9TeaAtBgTowyDfCGa0SzYUBA1sPVV7k84XL7QF8/s/oU44Af2mYb/yf sHo2FuzL7XE8Dq1XqiXRSgqmOr40SIdeInamk2U2AZSb/+BYf60EDuvXAYAP/Il6jocr IjOg==
X-Gm-Message-State: AOAM530WxWgxNjhZn4O2V2Vm7rCG9/mo0CbXJ44nP0RanfSWU02J80WY dfl1cq130Eqo0tycNUvNSMArRc910Mnb10mbZpc=
X-Google-Smtp-Source: ABdhPJyPC0VWycbEuvB6Gs5SJlF/koKfrYW9Hl01odURaXATWRYsyVAHpFB85hA4kswCEzec0/VwySbtdZXdHKoUT3U=
X-Received: by 2002:a2e:80cb:0:b0:255:775f:97b3 with SMTP id r11-20020a2e80cb000000b00255775f97b3mr15729165ljg.497.1654651483852; Tue, 07 Jun 2022 18:24:43 -0700 (PDT)
MIME-Version: 1.0
References: <CA+YzgTva1Bs=AaTW9+unRdyPPdTknG1XLRLXokZOFtE-+O99DQ@mail.gmail.com> <79b36750af70492db20bd9b04d08e1b7@huawei.com> <SJ0PR04MB83918CB0EFF3CC523D81C3D2CDDD9@SJ0PR04MB8391.namprd04.prod.outlook.com> <DB9PR06MB79153186F362EDCC014C5A939EDD9@DB9PR06MB7915.eurprd06.prod.outlook.com> <DB9PR06MB791556665C42AF35763D042C9EDD9@DB9PR06MB7915.eurprd06.prod.outlook.com> <ac4d8447388b4f87ba885b8844241cad@huawei.com> <SJ0PR04MB83912793E33E51D8A5E46D73CDDC9@SJ0PR04MB8391.namprd04.prod.outlook.com> <CA+YzgTu_Y+odfSsTm-QTawJOyqsYMmDyuZzfi7M-nzQkseWmsA@mail.gmail.com> <3b89bd3185bd4839b675c37461588416@huawei.com>
In-Reply-To: <3b89bd3185bd4839b675c37461588416@huawei.com>
From: Shunsuke Homma <s.homma0718@gmail.com>
Date: Wed, 08 Jun 2022 10:24:32 +0900
Message-ID: <CAGU6MPfWeeMo7JO5kO829QxWhBgED1bTFDCcZfc-snmvsMGeKA@mail.gmail.com>
To: "Gengxuesong (Geng Xuesong)" <gengxuesong=40huawei.com@dmarc.ietf.org>
Cc: Vishnu Pavan Beeram <vishnupavan@gmail.com>, "Rokui, Reza" <rrokui@ciena.com>, LUIS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmurillo@telefonica.com>, TEAS WG <teas@ietf.org>, Ivan Bykov <Ivan.Bykov@rbbn.com>, TEAS WG Chairs <teas-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ec15ab05e0e591d1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/xDckQ7qg-0D7t-I1WBPZxESgdI8>
Subject: Re: [Teas] Applicability of IETF network slices in the 3GPP context
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: Wed, 08 Jun 2022 01:24:50 -0000

Hi authors,

I have some questions on mapping(stitching?) of 3GPP and IETF network
slices as below, and I'll be happy if they are resolved in this work.

-  Is any special identifier, which is IETF-nodes aware (e.g., SID in an
IPv6 extension header, MPLS label, NSH, etc.), is needed for classification
on IETF NS PE? As you know, packets on N3 and N9 interfaces are
encapsulated  with GTP-U, and traffic assigned to different network slices
may have the same src/dst IP addresses. If we use some special identifier,
a standardized scheme for that would be needed, especially for
multi-administrative domains environment. Or, 3GPP 5G system is required to
deploy an interface or a UPF instance for each network slice?

- Are there any differences between procedures of mapping/stitching
3GPP-IETF network slices at RAN, 5G-Core, and DN (i.e., N3, N6, and N9
interfaces) ? (For example, information exchanged between IETF NSC and 5G
OpS, or classification scheme.) 5G has MEC scenarios and guaranteed
communication quality may be required in DN. On N6 packets are passed as
user-plane PDU, and network slices run on DN may be required to support
ethernet and unstructured forms, in addition to IPv4/v6 (ref TS23 501).
Also, 5G allows multiple access, and we may need to consider cases where
IETF network slices deployed on a fixed network (this is not TN within RAN)
connected to a 5G-core.

Regards,

Shunsuke




2022年6月3日(金) 12:01 Gengxuesong (Geng Xuesong) <gengxuesong=
40huawei.com@dmarc.ietf.org>:

> Thanks Pavan and Lou. The webex invite is received.
>
>
>
> *From:* Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com]
> *Sent:* Thursday, June 2, 2022 10:40 PM
> *To:* Rokui, Reza <rrokui@ciena.com>
> *Cc:* Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com>; LUIS MIGUEL
> CONTRERAS MURILLO <luismiguel.contrerasmurillo@telefonica.com>; TEAS WG <
> teas@ietf.org>; Ivan Bykov <Ivan.Bykov@rbbn.com>; TEAS WG Chairs <
> teas-chairs@ietf.org>
> *Subject:* Re: [Teas] Applicability of IETF network slices in the 3GPP
> context
>
>
>
> The meeting has been scheduled as requested (June 10th 8am US Eastern
> Time). The webex invite has been sent out to the list.
>
>
>
> Please note that this is an open informal session driven by the
> authors/contributors of the relevant drafts. The objective is to produce a
> single document on the topic that the TEAS WG can look to adopt.
>
>
>
> Regards,
>
> -Pavan and Lou
>
>
>
> On Tue, May 31, 2022 at 9:42 PM Rokui, Reza <rrokui@ciena.com> wrote:
>
> Hello TEAS chairs,
>
>
>
> To give more time to all co-authors, would it be possible to create a
> Webex meeting for Friday June 10 @ 8:00 EST
>
>
>
> Thanks,
>
> Reza
>
>
>
> *From: *Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com>
> *Date: *Tuesday, May 31, 2022 at 11:05 AM
> *To: *LUIS MIGUEL CONTRERAS MURILLO <
> luismiguel.contrerasmurillo@telefonica.com>, Rokui, Reza <rrokui@ciena.com>,
> Vishnu Pavan Beeram <vishnupavan@gmail.com>, TEAS WG <teas@ietf.org>,
> Ivan Bykov <Ivan.Bykov@rbbn.com>
> *Cc: *TEAS WG Chairs <teas-chairs@ietf.org>, Rokui, Reza <rrokui@ciena.com
> >
> *Subject: *[**EXTERNAL**] RE: [Teas] Applicability of IETF network slices
> in the 3GPP context
>
> Hi authors and WG,
>
>
>
> It is great to hear that people agree this topic is important and willing
> to work together.
>
>    1. Call meeting proposal
>
> Agree with Reza that a call meeting will be very helpful.
>
> -       Friday June 3 @ 8:00 EST
>
> -       Friday June 10 @ 8:00 EST
>
> These 2 time slots both work for me and the 1st one is preferred. Could
> chairs kindly help to book a webex meeting if the authors think the time is
> suitable?
>
>    1. Document merge proposal
>
> There are 3 documents in TEAS about this topic with slightly different
> side focus:
>
>    - *draft-geng-teas-network-slice-mapping* provides a procedure of
>    mapping 5G end-to-end network defined in 5GPP slice to transport network
>    slice defined in IETF, which gives guidance about how to use IETF network
>    slice in 5G scenario in management plane, control plane and data plane
>    respectively.
>    - *draft-contreras-teas-3gpp-ietf-slice-mapping* discusses mapping of
>    3GPP slice and IETF network slice endpoint and other related parameters,
>    which mainly focuses about how to provide connection between 3GPP
>    connection by IETF Network Slice with NSC
>    - *draft-rokui-5g-ietf-network-slice *discusses the relationship
>    between 5G E2E network slicing and IETF network slice for 5G use-case,
>    which also gives 5G IETF Network Slice NBI Information Model
>
>
>
> Here is an initial proposal about the structure for combining these 3
> documents:
>
>    - 5G End-to-End Network Slice Introduction  . . . . . . . . .
>    background information summarized from 3 documents
>    - Network Slice Mapping Structure . . . . . . . . . . . . . . .
>    draft-geng-teas-network-slice-mapping/draft-rokui-5g-ietf-network-slice
>    - Network Slice Mapping Parameters  . . . . . . . . . . . . . . .
>    draft-contreras-teas-3gpp-ietf-slice-mapping/
>    draft-geng-teas-network-slice-mapping
>    - Network Slice Mapping Procedure . . . . . . . . . . . . . . .
>    draft-geng-teas-network-slice-mapping
>
> Ÿ   Network Slice Mapping in Management Plane . . . . . . . .
> draft-contreras-teas-3gpp-ietf-slice-mapping
>
> Ÿ   Network Slice Mapping in Control Plane  . . . . . . . . .
> draft-geng-teas-network-slice-mapping
>
> Ÿ   Network Slice Mapping in Data Plane . . . . . . . . . . .
> draft-geng-teas-network-slice-mapping
>
>    - 5G IETF Network Slice NBI  . . . . . . . . . . . . . . . .
>    draft-rokui-5g-ietf-network-slice
>
>
>
> Best
>
> Xuesong
>
>
>
>
>
> *From:* LUIS MIGUEL CONTRERAS MURILLO [mailto:
> luismiguel.contrerasmurillo@telefonica.com]
> *Sent:* Tuesday, May 31, 2022 12:30 AM
> *To:* LUIS MIGUEL CONTRERAS MURILLO <
> luismiguel.contrerasmurillo@telefonica.com>; Rokui, Reza <rrokui@ciena.com>;
> Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com>; Vishnu Pavan Beeram <
> vishnupavan@gmail.com>; TEAS WG <teas@ietf.org>; Ivan Bykov <
> Ivan.Bykov@rbbn.com>
> *Cc:* TEAS WG Chairs <teas-chairs@ietf.org>; Rokui, Reza <rrokui@ciena.com
> >
> *Subject:* RE: [Teas] Applicability of IETF network slices in the 3GPP
> context
>
>
>
> Adding my co-author Ivan to this thread for commenting on the proposed
> slots for the tentative discussion.
>
>
>
> Best regards
>
>
>
> Luis
>
>
>
> *De:* LUIS MIGUEL CONTRERAS MURILLO <
> luismiguel.contrerasmurillo@telefonica.com>
> *Enviado el:* lunes, 30 de mayo de 2022 15:55
> *Para:* Rokui, Reza <rrokui=40ciena.com@dmarc.ietf.org>; Gengxuesong
> (Geng Xuesong) <gengxuesong=40huawei.com@dmarc.ietf.org>; Vishnu Pavan
> Beeram <vishnupavan@gmail.com>; TEAS WG <teas@ietf.org>
> *CC:* TEAS WG Chairs <teas-chairs@ietf.org>; Rokui, Reza <rrokui@ciena.com
> >
> *Asunto:* RE: [Teas] Applicability of IETF network slices in the 3GPP
> context
>
>
>
> Agree here, as well.
>
>
>
> I think we have complementary parts which are worthy to put together. On
> one hand there are generic architectural aspects that can show how 3GPP
> systems will act as upper systems of IETF NSC. There are also aspects on
> how 3GPP expects (as today) to requests slices at TN (in 3GPP terminology),
> which could show limitations (or undefined terms) on some of the required
> capabilities at the connectivity slices. And finally there are potential
> realizations today that could be documented.
>
>
>
> The task is huge, anyway, so we need to analyze what can be delivered for
> IETF114, maybe an structure of the merged content, hopefully something
> else. In any case, definitely worthy to work on it.
>
>
>
> Both dates as proposed by Reza are fine for me. I expect to do some
> preliminary work on proposition of parts to consider from the 3 drafts
> before the potential meeting, so we can advance with the work offline.
>
>
>
> Thanks,
>
>
>
> Best regards
>
>
>
> Luis
>
>
>
> *De:* Teas <teas-bounces@ietf.org> *En nombre de *Rokui, Reza
> *Enviado el:* lunes, 30 de mayo de 2022 14:59
> *Para:* Gengxuesong (Geng Xuesong) <
> gengxuesong=40huawei.com@dmarc.ietf.org>; Vishnu Pavan Beeram <
> vishnupavan@gmail.com>; TEAS WG <teas@ietf.org>
> *CC:* TEAS WG Chairs <teas-chairs@ietf.org>; Rokui, Reza <rrokui@ciena.com
> >
> *Asunto:* Re: [Teas] Applicability of IETF network slices in the 3GPP
> context
>
>
>
> Thanks Lou and Pavan,
>
> Agreed with your suggestion.
>
>
>
> To all authors of the three drafts mentioned below,
>
> It would be a good idea to have a meeting between us to decide about the
> next step. What is the best way to have this meeting? Does either of the
> following slots work for you?
>
>    - Friday June 3 @ 8:00 EST
>    - Friday June 10 @ 8:00 EST
>
> Cheers,
>
> Reza
>
>
>
> *From: *Teas <teas-bounces@ietf.org> on behalf of Gengxuesong (Geng
> Xuesong) <gengxuesong=40huawei.com@dmarc.ietf.org>
> *Date: *Thursday, May 26, 2022 at 3:49 AM
> *To: *Vishnu Pavan Beeram <vishnupavan@gmail.com>, TEAS WG <teas@ietf.org>
> *Cc: *TEAS WG Chairs <teas-chairs@ietf.org>
> *Subject: *[**EXTERNAL**] Re: [Teas] Applicability of IETF network slices
> in the 3GPP context
>
> Hi Pavan and Lou,
>
>
>
> Thanks for the suggestion. We will coordinate with the authors of other
> drafts.
>
>
>
> Best
>
> Xuesong
>
>
>
> *From:* Teas [mailto:teas-bounces@ietf.org <teas-bounces@ietf.org>] *On
> Behalf Of *Vishnu Pavan Beeram
> *Sent:* Wednesday, May 25, 2022 8:58 PM
> *To:* TEAS WG <teas@ietf.org>
> *Cc:* TEAS WG Chairs <teas-chairs@ietf.org>
> *Subject:* [Teas] Applicability of IETF network slices in the 3GPP context
>
>
>
> WG,
>
> We (the chairs) acknowledge that it is important for the WG to work on a
> document that discusses the applicability of IETF network slices in the
> 3GPP context.
>
>
>
> We have had 3 documents presented in past TEAS sessions that can form the
> basis of such a document:
>
>
> https://datatracker.ietf.org/doc/draft-contreras-teas-3gpp-ietf-slice-mapping/
> [datatracker.ietf.org]
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-contreras-teas-3gpp-ietf-slice-mapping/__;!!OSsGDw!MeCTM2ODJOQpcbP4VaxqGk4gua_Vi78oH8VsMeH8f7isG1X-DXxf1BRe0aWG0Ml7kcu9MAl_svtR5BwU3qWU5oOhIwk$>
>
> https://datatracker.ietf.org/doc/draft-geng-teas-network-slice-mapping
> [datatracker.ietf.org]
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-geng-teas-network-slice-mapping/__;!!OSsGDw!MeCTM2ODJOQpcbP4VaxqGk4gua_Vi78oH8VsMeH8f7isG1X-DXxf1BRe0aWG0Ml7kcu9MAl_svtR5BwU3qWUreVkEHI$>
>
> https://datatracker.ietf.org/doc/draft-rokui-5g-ietf-network-slice/
> [datatracker.ietf.org]
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-rokui-5g-ietf-network-slice/__;!!OSsGDw!MeCTM2ODJOQpcbP4VaxqGk4gua_Vi78oH8VsMeH8f7isG1X-DXxf1BRe0aWG0Ml7kcu9MAl_svtR5BwU3qWULIAwjco$>
>
>
>
> We encourage the authors of these documents to find ways to collaborate
> and produce a single document (ideally before IETF114) that the WG can look
> to adopt.
>
>
>
> Regards,
>
> -Pavan and Lou
>
>
> ------------------------------
>
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
> puede contener información privilegiada o confidencial y es para uso
> exclusivo de la persona o entidad de destino. Si no es usted. el
> destinatario indicado, queda notificado de que la lectura, utilización,
> divulgación y/o copia sin autorización puede estar prohibida en virtud de
> la legislación vigente. Si ha recibido este mensaje por error, le rogamos
> que nos lo comunique inmediatamente por esta misma vía y proceda a su
> destrucción.
>
> The information contained in this transmission is confidential and
> privileged information intended only for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited. If you have received
> this transmission in error, do not read it. Please immediately reply to the
> sender that you have received this communication in error and then delete
> it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
> pode conter informação privilegiada ou confidencial e é para uso exclusivo
> da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
> indicado, fica notificado de que a leitura, utilização, divulgação e/ou
> cópia sem autorização pode estar proibida em virtude da legislação vigente.
> Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique
> imediatamente por esta mesma via e proceda a sua destruição
>
>
> ------------------------------
>
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
> puede contener información privilegiada o confidencial y es para uso
> exclusivo de la persona o entidad de destino. Si no es usted. el
> destinatario indicado, queda notificado de que la lectura, utilización,
> divulgación y/o copia sin autorización puede estar prohibida en virtud de
> la legislación vigente. Si ha recibido este mensaje por error, le rogamos
> que nos lo comunique inmediatamente por esta misma vía y proceda a su
> destrucción.
>
> The information contained in this transmission is confidential and
> privileged information intended only for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited. If you have received
> this transmission in error, do not read it. Please immediately reply to the
> sender that you have received this communication in error and then delete
> it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
> pode conter informação privilegiada ou confidencial e é para uso exclusivo
> da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
> indicado, fica notificado de que a leitura, utilização, divulgação e/ou
> cópia sem autorização pode estar proibida em virtude da legislação vigente.
> Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique
> imediatamente por esta mesma via e proceda a sua destruição
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>