Return-Path: 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 B64C7C14F6E3; Fri, 27 Sep 2024 12:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.805 X-Spam-Level: X-Spam-Status: No, score=-2.805 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, 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_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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=olddog.co.uk 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 9gTZgrMHip3H; Fri, 27 Sep 2024 12:29:10 -0700 (PDT) Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68B15C14F6BF; Fri, 27 Sep 2024 12:29:09 -0700 (PDT) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta7.iomartmail.com (8.14.7/8.14.7) with ESMTP id 48RJT7Gt013843; Fri, 27 Sep 2024 20:29:07 +0100 Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5ED3A46050; Fri, 27 Sep 2024 20:29:07 +0100 (BST) Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4830C4604F; Fri, 27 Sep 2024 20:29:07 +0100 (BST) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs1.iomartmail.com (Postfix) with ESMTPS; Fri, 27 Sep 2024 20:29:07 +0100 (BST) Received: from LAPTOPK7AS653V (82-69-109-75.dsl.in-addr.zen.co.uk [82.69.109.75]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.7/8.14.7) with ESMTP id 48RJT1rA031604 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 27 Sep 2024 20:29:02 +0100 From: "Adrian Farrel" To: , "'TEAS WG'" References: <762136658.2244950.1727166111240@www.getmymail.co.uk> In-Reply-To: Date: Fri, 27 Sep 2024 20:29:03 +0100 Organization: Old Dog Consulting Message-ID: <01fb01db1113$8304c3e0$890e4ba0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01FC_01DB111B.E4CBEB00" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdsRE3o1jfC8jLYsRYKw1pX5vQN/yw== Content-Language: en-gb X-Originating-IP: 82.69.109.75 X-Thinkmail-Auth: adrian@olddog.co.uk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=olddog.co.uk; h=reply-to :from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type; s=20221128; bh=r4PN/UAXgAJlboF2leHme ouaGkc9i+QtoIOF4GTxvq0=; b=xMf44jyFETTEX6OZOYakk8Pg67WhplN5DOf29 t+4eLFzOwXHyTBYMsQ0d0G/3NjPCRt+gi1xK7DO0K3AVnTuSmw9dB+GLQS2N/t6k 2VNfut95VaDy9WRkow1TMgKHTgPgmMuMKlemtYoqr2wkppUvWDV5+XWgwJeFZZJB SC5yc3dRXZkwhlB2M7LSwDtRRgSUjmV53iIcdusViH0yBIYQnuNuPOEdTb0SVZ1L M3u8KjaY6QXMZKOjAzMc9dFSihLzVqpFVZfbDpiCfXxb8q5wLd8t3lV7FeqVR3cQ BD8X6Y8xi9W5TyY8ZtVVOMkGIyy6vVKWsW34XcG/pGRf6FQNA== X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-9.0.0.1002-28352.003 X-TM-AS-Result: No--43.161-10.0-31-10 X-imss-scan-details: No--43.161-10.0-31-10 X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1002-28352.003 X-TMASE-Result: 10--43.161100-10.000000 X-TMASE-MatchedRID: /zs+JtmqfZoZnuop9luYIDjNGpWCIvfTyeUl7aCTy8i+y4Y487IcAUmb /vjP+wrh8Xo3NKXpyhcvGJKrjcJjFaUEDxO9eWwqfb/LeMmmtRCRgLeuORRdEi99T+uJIleR/Fm 3ziqFqDq0LMwXr3wYw9J89O0njFJ+/0dTUjHNqgni3aa5wOREEUjmbQR0Nyy8teXjSBMYnmlcVM ejXN5JLzCum5Sq9K7w1meiMxrk1y0PuOFJBO/X0Pi3y7in4HTgp9XpWXAGZTTBl6NErXdqUNnfJ rUSEbFD/57ghY35qk4nhcxDj2B/mqDoVJOi9+FAXTubK8QEAhl4Xox68xVlQA0UKNNtdi1c7Vnw OKt0Tn+bt7yRkwwgYSajnHhn4HrCx9H/PjlgCcRaBnLjQM0IFCgmBa9ZkpHQpjlkbDvDJ4eT5mu jf2soH278DSzaDuLBsmy/ejrX9A3WcdASlk7lVtHu43wY4QfHNZEftOVQtYbMB0kPsl40w9SHnJ Dq2yhMkEwxBr8eEvfb9dCKvDUCVr4rLaI8HzqgTipLDaMylH2yTrWV4vwyX9GenxDH6mnrBuhMN LfO6UBp+mvjuoz8qQCOEItvuigA+5MHyYkXwcqq6D28gDZY4ARryDXHx6oXt0bzCFNtPZxVLrHo L1dJSENEEL4+tODZ2QFbUsMkd1+6iFy5ZwbYqDK0d825rftFodQJXaDex6dBqLOmHiM3w+UzenO HQLvDDr4NSK39t5Zr6uxoMitIhb3VqvDjHOXNxi///JpaHQPYUDvAr2Y/1/R0/RdNKluAalBnSe 2q2aXNY+9Kn8uNfIl/Op+/tsa74CdinuOy9BSeAiCmPx4NwGmRqNBHmBvexq6dn4PjJNkuAzYzf KDduFKMqIeOstifkU6UkIr/V+1nME/Jsn/m+g== X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0 Message-ID-Hash: U5JMWYK5HMK4LFIRFWFXALPGVGJ6MWIJ X-Message-ID-Hash: U5JMWYK5HMK4LFIRFWFXALPGVGJ6MWIJ X-MailFrom: adrian@olddog.co.uk X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-teas.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: 'TEAS WG Chairs' X-Mailman-Version: 3.3.9rc4 Precedence: list Reply-To: adrian@olddog.co.uk Subject: =?utf-8?q?=5BTeas=5D_Last-gasp_review_of_draft-ietf-teas-5g-ns-ip-mpls-11?= List-Id: Traffic Engineering Architecture and Signaling working group discussion list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: This is a multipart message in MIME format. ------=_NextPart_000_01FC_01DB111B.E4CBEB00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 Here (finally) is my additional review of this draft. Sorry to have=20 taken a few additional days. =20 Other than the comments (arising from Jie's review), I have only=20 found a small points and a couple of nits. =20 Not sure whether I should have spotted these in previous reviews. If so, sorry. =20 Thanks for all the work. =20 Cheers, Adrian =20 =3D=3D=3D =20 idnits shows " Unused Reference: 'TR-GSTR-TN5G' " =20 --- =20 Section 2, having said the document makes use of the terms defined in RFC 9543, proceeds to provide a new definition of "customer" and=20 "provider". I wonder whether those new definitions are necessary, and=20 if they are I think great care is needed to achieve disambiguation. =20 --- =20 In Section 3.1, piping ("|") is used to indicated quoted text from 3GGPP documents. That's good. But:=20 - It is probably de trop to use quotation marks as well. - It appears as though the reference is part of the quote. =20 --- =20 3.2.1 =20 Ditto the use of | and " =20 --- =20 3.2.2 =20 I don't object to one word of the text in 3.2.2. I do find it peculiar that, while 3.2.1 is nicely quoted from 3GPP documentation, the text in this section is longer and un-cited. =20 I should imagine that the paragraph... The objective of Transport Network Slicing is ...should be founded in a 3GPP definition. =20 While the first half of the paragraph... Transport Network Slicing provides various degrees of sharing of resources between slices ...presumably stems from 9543 =20 The rest of the text is explanatory in the context of this document (and maybe should say so). =20 --- =20 Slice scopes and SDP locations. =20 It is all really confusing to me, and I do not arrive at anything other than contradictions from the text :-( =20 Figure 1 shows the TN slice and also shows the type 3 and type 4 SDP locations. =20 But, an SDP is the point at which the slice service begins or ends. It is the edge of the slice. =20 Either: - You are saying that a transport slice does not map perfectly to an IETF slice Or: - There is something wrong with this and the text in 3.4.2. =20 I don't think any of this changes any of the technical details or practicalities of the solutions described. It just that the description seems plain wrong. =20 For example, where you talk about mapping service parameters: where is that mapping performed? The question, I suppose is, are you=20 constructing a TN slice that encompasses network resources that are both IETF and non-IETF. In that case, the service parameters are mapped at the edge of the TN slice, and then they are mapped again at the network boundary at the start of the IETF technology. =20 If your intention is that the TN slice is constructed from elements of the customer domain (possibly non-IETF) and the provider domain (IETF), that would be fine, but I think the TN slice end points are still the=20 SDPs. =20 If, conversely, you are saying that the TN slice is a composite of customer domain slice and IETF slice, then you have the SDPs correctly placed, but you have not made this composite clear. =20 It does not help that 3.4.2 goes on to say: The concept of distributed PE (Section 3.3.4) assimilates CE-based SDPs defined in Section 5.2 of [RFC9543] (i.e., Types 1 and 2) as SDP Type 3 or 4 in this document. =20 The problem is not with the text, but with the fact that your Figure 6 shows the TN slice extending to the CEs in a model where the CEs are distinct from the PEs. (To me it seems that you are doing types 1 and 2 in this document with the case of distributed PE assimilating types 3 and 4.) =20 I start to run into some of this again in Section 4. For example, in 4.1 In this option, the RFC 9543 Network Slice, fulfilling connectivity requirements between NFs that belong to a 5G slice, is represented at an SDP by a VLAN ID (or double VLAN IDs, commonly known as QinQ), as depicted in Figure 12. That suggests to me that the model in your head is that the VLAN ID is=20 indicative of either: - onto which IETF slice the SDP should place the traffic (the traffic=20 is at that stage not yet sliced only marked for slicing) or: - on which IETF slice the traffic is flowing (the traffic has already been sliced and the SDP is actually at the end of the TN slice). =20 To complete my whining about this, 4.2 shows the "tunnels representing slices" as extending all the way to the NFs (CEs not marked). Surely, in that case, the SDP is at the end of the tunnel? =20 =20 I'd be quite happy with either or any approach. I just want the=20 description to match. =20 --- =20 3.6 =20 At the time of writing (2024), Section 6.1.2 of [NG.113] specifies =20 Well... NG.113 is a dated reference. Doesn't that mean that you can simply say =20 Section 6.1.2 of [NG.113] specifies =20 While it is true that 3GGP's "5GS Roaming Guidelines" may change over time. The referenced Version 4 dated 2021 will not change. =20 --- =20 3.7 =20 s/of [RFC9522])./of [RFC9522]./ =20 --- =20 Figure 11 =20 Is there an arrow head missing from the left hand end of the line within the right hand P node? =20 From: mohamed.boucadair@orange.com =20 Sent: 24 September 2024 09:47 To: Adrian Farrel ; Vishnu Pavan Beeram ; TEAS WG Cc: TEAS WG Chairs Subject: [Teas] Re: Responses for LS on "Realization of Network Slices = for 5G Networks Using Current IP/MPLS Technologies" =20 Hi Adrian, =20 Deal! Thank you for your efforts.=20 =20 I also hope that Jie can check and let us know if we missed any of his comments. =20 Cheers, Med =20 De : Adrian Farrel =20 Envoy=E9 : mardi 24 septembre 2024 10:22 =C0 : BOUCADAIR Mohamed INNOV/NET ; Vishnu = Pavan Beeram ; TEAS WG Cc : TEAS WG Chairs Objet : [Teas] Re: Responses for LS on "Realization of Network Slices = for 5G Networks Using Current IP/MPLS Technologies" =20 Thanks to all for the hard work on this document. It is definitely = getting much better (and shorter) which is a good thing for all of us.=20 =20 There does seem to have been a lot of changes sine the first last call, = and even since the second one. It also looks (to me) that there are a few of Jie's comments still unresolved.=20 =20 I plan to scan the doc tonight and I'll try to suggest resolutions for = the points that look to be still open.=20 =20 A=20 On 24/09/2024 10:05 CEST mohamed.boucadair@orange.com wrote:=20 =20 =20 Hi Pavan, all,=20 =20 FWIW, the changes are now implemented in the public version together = with additional follow-up comments from Jie: https://datatracker.ietf.org/doc/draft-ietf-teas-5g-ns-ip-mpls/11/.=20 =20 Cheers, Med =20 De : BOUCADAIR Mohamed INNOV/NET=20 Envoy=E9 : lundi 9 septembre 2024 15:34 =C0 : 'Vishnu Pavan Beeram' >; TEAS WG > Cc : TEAS WG Chairs = > Objet : RE: [Teas] Responses for LS on "Realization of Network Slices = for 5G Networks Using Current IP/MPLS Technologies" =20 Hi Pavan, all, =20 Thanks for sharing your conclusions.=20 =20 Looks good to me. Fixed right now the ref nits: https://github.com/boucadair/5g-slice-realization/commit/3c11d6e6baa2f50a= 10a 95904c8abb29753e91034. These nits can be queues for a next iteration = when we will have more comments, but we can release a new version if you prefer = so. Thanks. =20 Cheers, Med =20 De : Vishnu Pavan Beeram >=20 Envoy=E9 : lundi 9 septembre 2024 10:04 =C0 : TEAS WG > Cc : TEAS WG Chairs = > Objet : [Teas] Responses for LS on "Realization of Network Slices for 5G Networks Using Current IP/MPLS Technologies" =20 WG, =20 We sent a liaison statement [1] in June to multiple 3GPP groups seeking feedback on our WG draft that discusses =93Realization of Network Slices = for 5G Networks Using Current IP/MPLS Technologies=94 [2].=20 We have received replies from 3GPP-TSGSA-SA2 [3], 3GPP-TSG-SA-WG5 [4] = and O3GPPTSGRAN3 [5]. We request the WG to review the feedback and chime in = with your thoughts/opinions. =20 The following is our (chairs=92) interpretation of the feedback that was received. =20 * 3GPP-TSGSA-SA2: * Remove Appendices B.1 and B.2 and just have a reference to TS-23.501 * No endorsement of the =93Hand-off=94 options discussed in Section 4 = and the QoS Mapping Realization Models in Section 5 * This need not warrant any changes to Sections 4 and 5. We need to ensure that the language used in these two sections doesn=92t imply any endorsement by 3GPP. * 3GPP-TSG-SA-WG5: * Fix the reference to 3GPP TS 28.530 * O3GPPTSGRAN3: * Inaccuracies exist in Appendix B.3. Suggest adding references to TS-38.300 and TS-38.401 * In other words, this is a recommendation to remove Appendix B.3. =20 Based on the above, our recommendation is to remove Appendix B = (including the Transport Network specific sub-section) and add the suggested = references in the Introduction. The authors have published a new revision (rev 10) = with Appendix B removed. Please review the latest changes and let us know if there are any comments/concerns. =20 Regards, -Pavan and Oscar=20 =20 [1] https://datatracker.ietf.org/liaison/1931/ [2] = https://datatracker.ietf.org/doc/html/draft-ietf-teas-5g-ns-ip-mpls [3] https://datatracker.ietf.org/liaison/1955/ [4] https://datatracker.ietf.org/liaison/1956/ [5] https://datatracker.ietf.org/liaison/1957/ =20 _________________________________________________________________________= ___ ________________________________ 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. =20 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. _______________________________________________=20 Teas mailing list -- teas@ietf.org =20 To unsubscribe send an email to teas-leave@ietf.org =20 _________________________________________________________________________= ___ ________________________________ 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. =20 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. ------=_NextPart_000_01FC_01DB111B.E4CBEB00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

Here = (finally) is my additional review of this draft. Sorry to have =

taken a few additional = days.

 

Other than = the comments (arising from Jie's review), I have only =

found a small points and a couple = of nits.

 

Not sure = whether I should have spotted these in previous reviews. If = so,

sorry.

 

Thanks for = all the work.

 

Cheers,

Adrian

 

=3D=3D=3D

 

idnits = shows " Unused Reference: 'TR-GSTR-TN5G' = "

 

---

 

Section 2, = having said the document makes use of the terms defined = in

RFC 9543, proceeds to provide a new = definition of "customer" and

"provider". I wonder = whether those new definitions are necessary, and =

if they are I think great care is = needed to achieve disambiguation.

 

---

 

In Section = 3.1, piping ("|") is used to indicated quoted text from = 3GGPP

documents. That's = good.

But:

- It is = probably de trop to use quotation marks as well.

- It = appears as though the reference is part of the = quote.

 

---

 

3.2.1

 

Ditto the = use of | and "

 

---

 

3.2.2

 

I don't = object to one word of the text in 3.2.2. I do find it = peculiar

that, while 3.2.1 is nicely quoted = from 3GPP documentation, the text in

this = section is longer and un-cited.

 

I should = imagine that the paragraph...

=A0=A0=A0 = The objective of Transport Network Slicing is

...should = be founded in a 3GPP definition.

 

While the = first half of the paragraph...

=A0=A0 = Transport Network Slicing provides various degrees of sharing = of

=A0=A0 resources between = slices

...presumably stems from = 9543

 

The rest of = the text is explanatory in the context of this document = (and

maybe should say = so).

 

---

 

Slice = scopes and SDP locations.

 

It is all = really confusing to me, and I do not arrive at anything = other

than contradictions from the text = :-(

 

Figure 1 = shows the TN slice and also shows the type 3 and type 4 = SDP

locations.

 

But, an SDP = is the point at which the slice service begins or ends. = It

is the edge of the = slice.

 

Either:

- You are = saying that a transport slice does not map perfectly to = an

=A0 IETF = slice

Or:

- There is = something wrong with this and the text in 3.4.2.

 

I don't = think any of this changes any of the technical details = or

practicalities of the solutions = described. It just that the description

seems plain = wrong.

 

For = example, where you talk about mapping service parameters: = where

is that mapping performed? The = question, I suppose is, are you

constructing a TN slice that = encompasses network resources that are

both IETF = and non-IETF. In that case, the service parameters = are

mapped at the edge of the TN slice, = and then they are mapped again

at the = network boundary at the start of the IETF = technology.

 

If your = intention is that the TN slice is constructed from elements = of

the customer domain (possibly = non-IETF) and the provider domain (IETF),

that would = be fine, but I think the TN slice end points are still the =

SDPs.

 

If, = conversely, you are saying that the TN slice is a composite = of

customer domain slice and IETF = slice, then you have the SDPs correctly

placed, but = you have not made this composite clear.

 

It does not = help that 3.4.2 goes on to say:

=A0=A0 The = concept of distributed PE (Section 3.3.4) assimilates = CE-based

=A0=A0 SDPs defined in Section 5.2 = of [RFC9543] (i.e., Types 1 and 2) as SDP

=A0=A0 Type = 3 or 4 in this document.

 

The problem = is not with the text, but with the fact that your Figure = 6

shows the TN slice extending to the = CEs in a model where the CEs are

distinct = from the PEs. (To me it seems that you are doing types 1 and = 2

in this document with the case of = distributed PE assimilating types 3

and = 4.)

 

I start to = run into some of this again in Section 4. For example, in = 4.1

=A0=A0 In this option, the RFC 9543 = Network Slice, fulfilling connectivity

=A0=A0 = requirements between NFs that belong to a 5G slice, is represented = at

=A0=A0 an SDP by a VLAN ID (or = double VLAN IDs, commonly known as QinQ), as

=A0=A0 = depicted in Figure 12.

That suggests to me that the model = in your head is that the VLAN ID is

indicative = of either:

- onto which IETF slice the SDP = should place the traffic (the traffic

=A0=A0is at = that stage not yet sliced only marked for = slicing)

or:

- on which = IETF slice the traffic is flowing (the traffic has = already

=A0 been sliced and the SDP is = actually at the end of the TN slice).

 

To complete = my whining about this, 4.2 shows the "tunnels = representing

slices" as extending all the = way to the NFs (CEs not marked). Surely,

in that = case, the SDP is at the end of the tunnel?

 

 

I'd be = quite happy with either or any approach. I just want the =

description to = match.

 

---

 

3.6

 

=A0=A0 At = the time of writing (2024), Section 6.1.2 of [NG.113] = specifies

 

Well...

NG.113 is a = dated reference. Doesn't that mean that you can simply = say

 

=A0=A0 = Section 6.1.2 of [NG.113] specifies

 

While it is = true that 3GGP's "5GS Roaming Guidelines" may change = over

time. The referenced Version 4 = dated 2021 will not change.

 

---

 

3.7

 

s/of = [RFC9522])./of [RFC9522]./

 

---

 

Figure = 11

 

Is there an = arrow head missing from the left hand end of the line = within

the right hand P = node?

 

From: = mohamed.boucadair@orange.com <mohamed.boucadair@orange.com> =
Sent: 24 September 2024 09:47
To: Adrian Farrel = <adrian@olddog.co.uk>; Vishnu Pavan Beeram = <vishnupavan@gmail.com>; TEAS WG = <teas@ietf.org>
Cc: TEAS WG Chairs = <teas-chairs@ietf.org>
Subject: [Teas] Re: Responses for = LS on "Realization of Network Slices for 5G Networks Using Current = IP/MPLS Technologies"

 

Hi Adrian,

 

Deal! Thank you for your efforts. =

 

I also hope that Jie can check and let = us know if we missed any of his comments.

 

Cheers,

Med

 

De : Adrian Farrel = <adrian@olddog.co.uk>
Envoy=E9 : mardi 24 = septembre 2024 10:22
=C0 : BOUCADAIR Mohamed INNOV/NET = <mohamed.boucadair@orange.com>; Vishnu Pavan Beeram = <vishnupavan@gmail.com>; TEAS WG = <teas@ietf.org>
Cc : TEAS WG Chairs = <teas-chairs@ietf.org>
Objet : [Teas] Re: Responses = for LS on "Realization of Network Slices for 5G Networks Using = Current IP/MPLS Technologies"

 

Thanks to all for the hard work on = this document. It is definitely getting much = better (and shorter) which is a good thing for all of us. =

 

There does seem to have been a lot of = changes sine the first last call, and even since the second one. It also = looks (to me) that there are a few of Jie's comments still unresolved. =

 

I plan to scan the doc tonight and = I'll try to suggest resolutions for the points that look to be still = open.

 

A =

On 24/09/2024 10:05 CEST mohamed.boucadair@orange.com= wrote:

 

  =

Hi Pavan, all,

 

FWIW, the changes are now implemented = in the public version together with additional follow-up comments from = Jie: https://datatracker.ietf.org/doc/draft-ietf-teas-5g-ns-ip-mpls/11/= .

 

Cheers,

Med

 

De : BOUCADAIR Mohamed INNOV/NET
Envoy=E9 : lundi 9 septembre 2024 15:34
=C0 : = 'Vishnu Pavan Beeram' <vishnupavan@gmail.com>; = TEAS WG <teas@ietf.org>
Cc : = TEAS WG Chairs <teas-chairs@ietf.org>
Objet : = RE: [Teas] Responses for LS on "Realization of Network Slices for = 5G Networks Using Current IP/MPLS = Technologies"

 

Hi Pavan, all,

 

Thanks for sharing your conclusions. =

 

Looks good to me. Fixed right now the = ref nits: https://github.com/boucadair/5g-slice-r= ealization/commit/3c11d6e6baa2f50a10a95904c8abb29753e91034. These = nits can be queues for a next iteration when we will have more comments, = but we can release a new version if you prefer so. Thanks.

 

Cheers,

Med

 

De : Vishnu Pavan Beeram <vishnupavan@gmail.com> =
Envoy=E9 : lundi 9 septembre 2024 10:04
=C0 : = TEAS WG <teas@ietf.org>
Cc : = TEAS WG Chairs <teas-chairs@ietf.org>
Objet : = [Teas] Responses for LS on "Realization of Network Slices for 5G = Networks Using Current IP/MPLS = Technologies"

 

WG,

 

We sent = a liaison statement [1] in June to multiple 3GPP groups seeking feedback = on our WG draft that discusses “Realization of Network Slices for = 5G Networks Using Current IP/MPLS Technologies” [2]. 

We have = received replies from 3GPP-TSGSA-SA2 [3], = 3GPP-TSG-SA-WG5 [4] and O3GPPTSGRAN3 [5]. We request the WG to review = the feedback and chime in with your thoughts/opinions.

 

The = following is our (chairs’) interpretation of the feedback that was = received.

 

  • 3GPP-TSGSA-SA2:
    • Remove Appendices B.1 and B.2 = and just have a reference to TS-23.501
    • No = endorsement of the “Hand-off” options discussed in Section 4 = and the QoS Mapping Realization Models in Section 5
      • This need not warrant any = changes to Sections 4 and 5. We need to ensure that the language used in = these two sections doesn’t imply any endorsement by = 3GPP.
  • 3GPP-TSG-SA-WG5:
    • Fix the reference to 3GPP TS = 28.530
  • O3GPPTSGRAN3:
    • Inaccuracies exist in Appendix = B.3. Suggest adding references to TS-38.300 and TS-38.401
      • In = other words, this is a recommendation to remove Appendix = B.3.

 

Based = on the above, our recommendation is to remove Appendix B (including the = Transport Network specific sub-section) and add the suggested references = in the Introduction. The authors have published a new revision (rev 10) = with Appendix B removed. Please review the latest changes and let us = know if there are any comments/concerns.

 

Regards,

-Pavan = and Oscar 

 

[1] https://datatracker.ietf.org/liaison/1931/=

[2] https://datatracker.ietf.org/doc/html/draft-ietf-= teas-5g-ns-ip-mpls

[3] https://datatracker.ietf.org/liaison/1955/=

[4] https://datatracker.ietf.org/liaison/1956/=

[5] https://datatracker.ietf.org/liaison/1957/=

 

_______________________________________________________________=
_____________________________________________
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.

_______________________________________________
Teas = mailing list -- teas@ietf.org =
To unsubscribe send an email to teas-leave@ietf.org = 

_______________________________________________________________=
_____________________________________________
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.
------=_NextPart_000_01FC_01DB111B.E4CBEB00--