Re: [Teas] WG adoption poll: draft-srld-teas-5g-slicing-06

Krzysztof Szarkowicz <kszarkowicz@gmail.com> Tue, 09 May 2023 17:16 UTC

Return-Path: <kszarkowicz@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 DD54DC14CF1E for <teas@ietfa.amsl.com>; Tue, 9 May 2023 10:16:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 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_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable 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 P_dCIGLV8yDa for <teas@ietfa.amsl.com>; Tue, 9 May 2023 10:16:28 -0700 (PDT)
Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 6F35DC14CEFE for <teas@ietf.org>; Tue, 9 May 2023 10:16:28 -0700 (PDT)
Received: by mail-qk1-x729.google.com with SMTP id af79cd13be357-7577ef2fa31so792189785a.0 for <teas@ietf.org>; Tue, 09 May 2023 10:16:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683652586; x=1686244586; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=SMDy6+PMQDTkAM9FXyxBrUe0HAC584/qQbnWj/4sh7E=; b=WQD4GRZq0l94BOr2bhkJ9NBeBh2ZTYCmMvQ+EDHKBy6XfVupiygD+V1RJjNT14zJK+ okT3PURLujNpRAAE5CQmNcuUJGcXBjnJRcU6o/bU5FSXds0MecWC25bohVsULS9vl7IT /u9PXtUg+S495p2VFElob0aAAL5p6fWKda6OO+4Kqk9F8HD5HNFzEsEKSMRpDjVMHz6M MZOKTtKkQx1atdWUZgQxG4kABHyiqwqs9guTQ8Jq00/Hl8qV0mBGu+mmqpMJp9bwfX+9 2lPep9olqSMTTEIdvm6CrUoG7B9AzV2ezGB2oZ/dmo6I8FliHtiJeeZ2lmz5rd+jrks/ 3RjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683652586; x=1686244586; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=SMDy6+PMQDTkAM9FXyxBrUe0HAC584/qQbnWj/4sh7E=; b=SuUGb/TLq1mffeYlLZjf/PLMxRpzIq8mGKDxUO6voG7jnbilEbjPI195AkbkUvsaeb wjGPHVhFFaBhAhHTguaVHE7vINPh1ixGrAlA9WAIL/EkubfbnlhyoCl6RxHboVsl4HlV JidAoKuPWQ3o67UUxsq8MFEbDy9EWEbnm+amRbFEkTiQ0ubcaR/kRdT5kKjgbQbSMM2m RI3bl3u8utG2cGFp69j4I7Qmlw4LDqX8OHUkzLHqcagJEjlXJhQElfgSdw11Fx3UANaJ qjHOFT05IhwIp6X7J1LB/F0vg78fL7uh8Q9zjKz0U1X9TjAcfXb3CFGCXfENeBFFDcdh pkPQ==
X-Gm-Message-State: AC+VfDw9ydELM+Wlye/0R6oikdWLB43LMC/mgc1vl572UONf8hQ7dRgA jcxWusvgXZyjRnLrq1HELpk=
X-Google-Smtp-Source: ACHHUZ48bYHh6mFtZgye8DEhlpuo2azLeUzDeJC0gqolyEhT8Iab7nzXI5PpcYkxlSg3SaNbDObZSg==
X-Received: by 2002:ad4:5d44:0:b0:5fd:93b7:5a96 with SMTP id jk4-20020ad45d44000000b005fd93b75a96mr23657240qvb.26.1683652585547; Tue, 09 May 2023 10:16:25 -0700 (PDT)
Received: from smtpclient.apple (jpams-nat14.juniper.net. [193.110.49.14]) by smtp.gmail.com with ESMTPSA id ne19-20020a056214425300b0061b7c0ff41dsm912542qvb.34.2023.05.09.10.16.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 May 2023 10:16:24 -0700 (PDT)
From: Krzysztof Szarkowicz <kszarkowicz@gmail.com>
Message-Id: <9D885F90-6973-4478-995C-C0CEBC36B2DF@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1BFF2CEC-A875-429D-8EBA-2AD42C3DE1E0"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.3\))
Date: Tue, 09 May 2023 19:16:21 +0200
In-Reply-To: <c50bb7d02b3a43fdabd8caae4756a6b9@huawei.com>
Cc: Oscar González de Dios <oscar.gonzalezdedios@telefonica.com>, TEAS WG <teas@ietf.org>
To: "Dongjie (Jimmy)" <jie.dong=40huawei.com@dmarc.ietf.org>
References: <PAXPR06MB7872C13D819D9FA23362E06CFD929@PAXPR06MB7872.eurprd06.prod.outlook.com> <c50bb7d02b3a43fdabd8caae4756a6b9@huawei.com>
X-Mailer: Apple Mail (2.3696.120.41.1.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/DJuC9nmDa3drcCwMa990ntLirac>
Subject: Re: [Teas] WG adoption poll: draft-srld-teas-5g-slicing-06
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, 09 May 2023 17:16:31 -0000

Hi Jie,

Thanks a lot for your review.

Let me address (inline) some comments.


Best regards,
Krzysztof

> On 2023 -May-06, at 11:26, Dongjie (Jimmy) <jie.dong=40huawei.com@dmarc.ietf.org> wrote:
> 
> Hi Oscar and authors,
>  
> Sorry for the late response to this adoption poll. I’ve finished my reading of this document (initially based on the -06 version, then a double check on the -07/08 version), please find some comments as below. It would be good if those comments could be considered before this document is adopted.
>  
>  
> - The title of the draft
> The title says it describes “a realization of IETF network slices”, but the content is not just about the realization of IETF network slice itself, it also has large amount of content related to the 5G network slice and QoS mapping to IETF network slices. Maybe the title could be modified to reflect the content better.


[Krzysztof] To be more precise, in the title we have “ a realization of IETF Network Slices for 5G Networks …”, so it is obvious, that the draft has content related to 5G, too. QoS (policers/shapers/queues/mapping/…, different Edge and Core QoS) is part of realization.
 
> - The Introduction
> It says this document provides an IETF network slice realization model with "a focus on fulfilling the 5G slicing connectivity requirements". Does this mean the SLO and SLE requirements are not the focus of this model/document? Suggest to clarify what the connectivity requirements means in this document.

[Krzysztof] The document focuses on fulfilling the 5G slicing connectivity requirement.  Which is connectivity requirements between 5G network functions (UPF, CU, DU, …), as depicted in many diagrams in the document. Obviously, these requirements are expressed as SLO/SLE. The authors of the document are involved in Change Requests related to 3GPP SA5 EP_Transport data structure (through which 5G NSO - Network Slice Orchestrator - expresses the connectivity requirements towards Transport Network, and are subsequently mapped to NSSI), allowing for more flexible and structured way to express these connectivity requirements. Once the CR is approved by 3GPP SA5, this draft will updated accordingly.

>  
>                                 
> - Conventions and Definitions
> Some of the terms are different from those used in IETF, such as SMO, ETN.  I found ETN is removed in version -08, and SMO is now moved into the appendix, but it is never used in the main text, so maybe SMO can also be removed.

[Krzysztof] Yep. ETN and SMO are now removed from the main text, and only CE and PE (including distributed version of CE and PE) is used in version -08, to align better with IETF network slice framework document. Agreed, we might remove SMO from appendix in the next revision.

>  
>  
> - Section 3.1 provides a picture about the scope of Transport network vs RAN and CN, while in the picture it is not clear where the NFs of RAN and CN reside in. Should they also be part of the DC or the public cloud? And TN only provides the connectivity in the DC and cloud.

[Krzysztof] Let us think about making the picture (and text describing the picture) clearer.

>  
>  
> - Section 3.2 mentions “TN Slicing provides various degrees of sharing of resources between slices”. Is this essentially the same as “various degrees of isolation”? 

[Krzysztof] IETF network slice framework doesn’t define the term "various degrees of isolation”, so we are not sure, what you understand by “various degrees of isolation”. Consequently, this draft does not use term “various degrees of isolation” (unless this term is clearly defined in the framework document).

>  
>  
> - Section 3.2 gives an example of TN slice resource management: 
>       “For example, shared TN resources could be provided in the backhaul, and dedicated TN resources could be provided in the midhaul.”
>      
>      Suggest to provide some reasoning why TN resources can be shared in the backhaul, while dedicated resource is needed in the midhaul.

[Krzysztof] There could be various business or technical reasons. Let us think, if we can make the text more clear.

>  
> - Section 3.3.1, It is not clear what is the purpose of this subsection, does the single or distributed PE or CE model have different impact to the IETF network slice realization? If so, maybe it is better to be elaborated. 


[Krzysztof] Indeed. It has the impact on IETF network slice realization, especially on AC definition - what is AC (and SDP placement). I.e., AC might be between ‘CE' and ‘managed CE’ (which is part of distributed PE), as depicted in the diagrams. 

>  
>  
> - Section 3.3.2, it is a little bit confusing to use inter-AS option B/C to model the AC between CE and PE, as it was used between PEs or ASBRs.  And the interpretation of ASBR and PE in inter-AS option C as an example of “distributed PE” is something unusual for an IETF document. There may be deployments using such mechanisms, while the description may cause confusion in IETF.

[Krzysztof] This is one of the deployment models in 5G, where NFs are virtualized on some compute node(s) in the DC, and service instantiation (i.e., L3VPN) happens on the commute node. And - indeed - DC might be different AS, so from BGP perspective it might be ASBR. In this deployment model, the AC, as defined by the IETF network slice framework document, transmits packets with already MPLS (or SRv6) encap.

>  
>  
> - Section 3.4.1, it is not clear to me whether the TN slice in the customer site is out of the scope of IETF network slice, if it uses IETF technologies for slice instantiation. 

[Krzysztof] Customer site is not under IETF NSC orchestration control, but under customer site orchestration control (e.g. Kubernetes container orchestration).

>  
>  
> - Section 3.6. This section describes the first and the subsequent 5G network slices, For this document it may also need to describe the implications to the realization of IETF network slices. The figure shows some mapping examples, while some text would be helpful.

[Krzysztof] Let us think about adding some description here.

> - Section 4.1, 4.2 and 4.3.  The text in these subsections are more about the interworking and mapping (it is called hand-off in the draft) between 5G slices and IETF network slice, thus is not quite relevant to the title and the beginning of section 4 (overview of the realization model). This also has some overlap with section 7 of the 5G end-to-end slice applications draft.

[Krzysztof] Hand-off methods between different domains are part of realization of the connectivity between 5G NFs, which includes connectivity sections under IETF NSC control (i.e. provider network), and connectivity sections not under IETF NSC control (i.e. customer network).

>  
>  
> - Section 4.2. If S-NSSAI is encoded in the IPv6 addresses of NFs, since transport network is not aware of the S-NSSAIs, some mapping table for IP addresses to IETF network slice mapping would be needed on the PEs for mapping 5G network slices to IETF network slices correctly. Note that the mapping between 5G slices to IETF slices is not always 1:1.

[Krzysztof] Ack. The text provides an (optional) example for a deployment. The text discussed the mapping table ("The mapping table can be simplified …”)

>  
>  
> - Section 4.3. This section could simply describe the use of MPLS label as the data identifier for mapping 5G slices to IETF network slices. Not sure the details about how the MPLS label and route targets are distributed in BGP control plane are really needed. IMO a reference to RFC 4364 would be good enough.

[Krzysztof] RFC 4346 is referenced in the ext. However, RFC 4346 has no details related to slicing, hence the text and figures in the draft.

>  
>  
> - Section 5. If my understanding is correct, this section is mainly about the mapping of 5G QoS parameters to TN QoS parameters at the TN edge nodes (the PE). Then it is better to rename section 5.3 to “Realization of QoS Mapping Models”.

[Krzysztof] OK. Let us think about changing the section name.

>  
>  
> - Section 5.4.1 I’m not sure the details about the rate limiter mechanism are needed, perhaps reference to existing QoS RFCs would be suffice.

[Krzysztof] Admission control, with ingress policers/ratę-limiters is an important realization building block, hence described in the draft.

>  
>  
> -  Section 5.4.2. It seems contradicting that the beginning of section 5.4 says:
>  
>     “QoS enforcement on transit links is fully coarse (single NRP, sharing resources among all IETF Network Slices)”
>  
>     While section 5.4.2 says for some use cases “fine-grained resource control to guarantee at least CIR for each slice is required.”

[Krzysztof] First sentence yuo quoted is about transit links, while second sentence you quoted is about edge (attachment circuit) links (as in Figure 11). There is no contradiction here.

>  
>  
> - Section 5.6. Some text may be needed to explain why per-slice outbound resource control is needed on the edge nodes, while on the transit nodes only traffic-class based PHB is needed. For example, is there possibility of outbound direction congestion on the transit nodes due to the use cases described in section 5.4.2?

[Krzysztof] It is already covered in the 2nd paragraph of Section 5.6.

>  
>  
> - Section 6. Similar comments as Adrian’s, the relationship between transport plane and NRP needs to be clarified. In this document do you want to make it explicit that the transport planes are in the same NRP, thus share the same set of network resources? In that case they are just different set of transport paths with no per-plane resource reservation.

[Krzysztof] That is correct. They are just different set of transport paths, I.,e., one set optimized based on the link delay metric, another set optimized based on the IGP metric. This is described in the first paragraph of Section 6.

>  
>    And in section 6.1 and 6.2 it seems it is more about the mapping from QoS Class to transport planes, rather than the mapping from slices to transport planes.  This needs to be clarified in figure 28.  Actually figure 29 is correct in the content, while the title is a little bit misleading.

[Krzysztof] In figur 28, all traffic classes (packets with all DSCP values, set by NF based on 5QI) of given IETF network slice are mapped to single transport plane. In figure 29, mapping to transport planes is at DSCP (5QI) granularity. I.e. if single IETF network slice service has multiple traffic classes (multiple DSCPs) they might be mapped to different transport planes. Not sure, how the diagrams could be made clearer.

>  
>  
> - Section 7.2.1. It is not clear how SPF is related to bandwidth management?  The example in this section is to use latency metric for SPF or Flex-Algo path computation. 

[Krzysztof] Section 7.2.1 does note use Traffic Engineering toolset, while Sections 7.2.2 and 7.2.3 do use traffic engineering toolset. Section 7.2.1 is the simplest, where BW management is reduced to appropriate capacity planning (1), and eventually usage of multiple transport planes implemented with FA, so the traffic flows from ‘A” to ‘B’ are distributed across multiple paths (as they are using multipole transport planes), thus distrinuting the capacity across multiple paths. Sections 7.2.2 and 7.2.3 have more advanced bandwidth management schemes.

>  
>  
> Best regards,
> Jie
>  
> From: Teas [mailto:teas-bounces@ietf.org <mailto:teas-bounces@ietf.org>] On Behalf Of Oscar González de Dios
> Sent: Monday, April 3, 2023 8:56 AM
> To: 'TEAS WG' <teas@ietf.org <mailto:teas@ietf.org>>
> Subject: [Teas] WG adoption poll: draft-srld-teas-5g-slicing-06
>  
> Dear TEAS WG colleagues,
>  
> This email begins a 2-week adoption poll for:
>  
> https://datatracker.ietf.org/doc/draft-srld-teas-5g-slicing/ <https://datatracker.ietf.org/doc/draft-srld-teas-5g-slicing/>
>  
> There is no IPR disclosed for this document. All authors and contributors have replied to the IPR poll.
>  
> Please voice your support or objections to adoption on the list by the end of the day (any time zone) April  17th.
>  
> Thank you,
>  
>   Oscar (as Co-chair)
>  
>  
> 
> 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