[Teas] Re: Late WGLC review of draft-ietf-teas-5g-ns-ip-mpls

[Vishnu Pavan Beeram <[e-mail]>]

Please see inline (prefixed VPB) for response to the point where chairs'
input was requested.

Regards,
-Pavan (on behalf of the TEAS chairs)

On Tue, May 14, 2024 at 3:05 PM <[e-mail]> wrote:

> Hi Adrian,
>
>
>
> Thank you for the follow-up.
>
>
>
> Submitted right now a new version that attempts to capture the points
> discussed so far:
> https://datatracker.ietf.org/doc/draft-ietf-teas-5g-ns-ip-mpls/06/.
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Adrian Farrel <[e-mail]>
> *Envoyé :* jeudi 9 mai 2024 11:25
> *À :* 'Krzysztof Szarkowicz' <[e-mail]>
> *Cc :* 'TEAS WG' <[e-mail]>; 'TEAS WG Chairs' <[e-mail]>;
> [e-mail]; BOUCADAIR Mohamed INNOV/NET <
> [e-mail]>
> *Objet :* RE: Late WGLC review of draft-ietf-teas-5g-ns-ip-mpls
>
>
>
> Hi Krysztof and Med,
>
>
>
> Thanks for your efforts on this.
>
>
>
> I’ve cut out the agreed points and also the ones where you have a clear
> action (although I have not checked your git edits), so that this email
> serves as a marker of items still needing work.
>
>
>
> Best,
>
> Adrian
>
> The document could really benefit from the addition of a section
> called "Scalability Considerations."
>
> draft-ietf-teas-nrp-scalability says...
>
>   It is anticipated that any specification of a network slicing
>   protocol solution will include considerations of scalability
>   and discussion of the applicability of the solution.  This will
>   not denigrate any specific solution, but will help clarify the
>   type of deployment in which the solution is optimal while
>  providing advice about its limitations in other deployments.
>
> That seems like good advice and reasoning (even though your
> document is not actually a specification). That draft also gives
> a lot of help in understanding what the scalability concerns are,
> so you should be able to give god advice to people who want to
> deploy based on your draft as to what they should and should not
> do, and where they can expect to need to impose limits. Appendix
> A.1 of that draft may be particularly relevant to your draft.
>
> [Med] I hear the comment even if the NRP advice does not directly apply
> here. We added a new section about scalability implications and added new
> text to remind that we inherit scalability properties of current
> technologies. We added pointers for readers interested in such scalability
> assessment.
>
> [AF] Even your choice to have just one NRP is still an NRP, and thinking
> about scalability is important especially as the chosen approach does have
> some scaling limits. So thanks for the section.
>
> *[Med] ACK.*
>
>
> 3.1
>
>   The term "Transport Network" is used for disambiguation with
>   5G network (e.g., IP, packet-based forwarding vs RAN and CN).
>   Consequently, the disambiguation applies to Transport Network
>   Slicing vs. 5G End-to-End Network Slicing (Section 3.2) as well the
>   management domains: RAN, CN, and TN domains.
>
> I thought I understood what was meant by TN in this document
> until I reached this paragraph. The previous text in 3.1 (and in
> the references) seems clear as to what a TN is. This text,
> however, confuses me and I can't extract anything useful from it.
> After all, haven't you just explained that:
>
>   Appendix B provides an overview of 5G network building blocks:
>   the Radio Access Network (RAN), Core Network (CN), and
>
>   Transport Network (TN).  The Transport Network is defined by
>  the 3GPP as the "part supporting connectivity within and between
>  CN and RAN parts" (Section 1 of [TS-28.530]).
>
>
> [Med] This is still under discussion among authors.
>
> *[Med] With the updated Intro, we do think that this text is not needed
> anymore. So, deleted it.*
>
>
>
> Figure 5 finally makes it clear that you are trying to
> distinguish a "network slice" from a "TN slice".
>
>
> [Med] Bingo, but it is unfortunate to see that readers may find that
> mention too late. Updated the intro to call that out early in the doc.
>
> [AF] Excellent, but still dangling is…
>
>
> In practice, I think you are trying to say that the slices of the different
> domains may be combined to form an end-to-end slice in the
> IP/MPLS technology. This is certainly supported by 3.4.2 and is
> consistent with draft-li-teas-composite- network-slices, but you
> need to work out which way you are slicing (sic)
> this:
>
> - You could be slicing each domain and stitching the slices
>   together, in which case, you don't need nearly as much
>
>   detail because each domain is sliced under its own slice
>
>  controller/orchestrator, and the slices are simply joined.
> - You could be performing a variant of the above where
>
>    multiple customer domain slices may be carried across
>
>    the provider network by a single provider domain slice in
>
>    a hierarchical manner.
> - You could be performing a single slicing operation, end-to-end
>   across each of the domains, in which case your SDPs are in the
>
>   wrong place.
>
> I would say:
> 2. You need to work out what model you are trying to use for your
>   realisation, explain it, and stick to it.
>
> *[Med] I hope this is now better articulated with the changes.*
>
>
>
> ---
>
>
>
> In 3.4.2 and with reference to Figure 5, it appears that your
> realisation is based on RFC 9543 Figure 1 Type 3. That's great,
> could you say so somewhere early in the document? It would help.
>
> *[Med] Added a statement that the realization is based on types 3/4. *
>
>
> (It still wouldn't make clear whether you are stitching domain
> slices or running a full end-to-end slicing operation, but it
> might help drive the
> answer.)
>
> By the time we get to Figure 6, you are talking about "slice
> segments"
> and that is really helping because now we can consider stitching
> those segments together.
>
>
>
> *[Med] Moved that figure to the introduction.*
>
>
> On the other hand, you also say that the customer domain slice
> can be considered part of the RAN/CN domain and sliced
> accordingly. If they are part of the RAN/CN domain, they are not
> part of the TN domain, so perhaps there is a lot here that simply
> doesn't need to be said.
>
> ---
>
> 3.4.2
>
>   In other words, the main
>   focus for the enforcement of end-to-end SLOs is managed at the
>   Network Slice between PE interfaces connected to the AC.
>
> Would that be more clearly stated with reference to the SDP?
>
> *[Med] I think this is covered by the note about types 3/4.*
>
>
> ---
>
> 3.5
>
> There seems to be a difference between the title of the
> section...
>      Mapping Schemes Between 5G Network Slices and Transport
>     Network Slices
> ...and the first line of text
>   There are multiple options for mapping 5G Network Slices to TN
>   slices:
> That is, the text talks about a unidirectional mapping (5G to TN)
> while the title says "between".
>
> *[Med] Updated to “Mapping 5G Network Slices to Transport Network Slices”
> for consistency.*
>
>
> But I think I object to the word "mapping".
>
> While, in one
> direction, the word is fine and clearly describes how one type of
> slice is projected onto another type of slice, the problem is
> more complicated because in the other direction (at the receiving
> end of the data flow) we need to "un-map".
>
> *[Med] Why should we be concerned with that? Isn’t that part of the non-TN
> job?   *
>
> Additionally, I wonder whether the idea of 1:N is real.
>
> *[Med] It is in case only eMBB is supported.*
>
> Of
> course, the example you give is real (carrying CP and UP on
> different resources over the TN), but I wonder whether that is
> really only one 5G slice or, in fact, two. If the traffic uses
> only one slice in the RAN, then it seems that when it is handed
> off to the TN it would all appear as a single flow and could not
> be separated across the two TN slices. That doesn't stop M:N (see
> 3.6) being credible because in that case the 5G slice pairs (UP
> and CP) are "mapped" to one TN slice for all CP, and individual
> or aggregated TN slices for UP traffic. 3.6 seems to recognise
> this by having a global 5G slice for eMBB (i.e., not just a
> special TN slice).
>
> ---
>
>
>
> 4.
>
>   these methods are not
>   reproduced here because of the intrinsic shortcomings of these
>   methods.
>
> Now, you say "intrinsic shortcomings" and some might find that
> pejorative. Does draft-ietf-teas-5g-network-slice-application
> describe those shortcomings? If so, you might just include a
> pointer. Otherwise, you either have to describe the shortcomings
> (not recommended) or simplify the text because we are not
> interested in what you don't do and more interested in what you
> do do (and why).
>
>
> [Med] Deleted " intrinsic" but cited examples of complications of such
> modes. For example, relying a source port number for identification is a
> poor design in the presence of NATs.
>
> [AF] Muttering a little. It is certainly better to give examples, rather
> than the previous simple statement.
>
> However, you are getting into a debate about which way to do things and I
> seems that we might not want to get into a detailed debate about why some
> solutions are good in some situations.
>
> Why can’t you let your approach stand for itself?
>
> *[Med] We prefer to not delete it to explain why we don’t mirror all the
> options in the app draft.*
>
>
> Section 4 is pretty clear and helpful. Thanks. I think it is
> where the real work of the draft begins (23 pages in). I wonder
> whether we can do something to get here more quickly.
>
> [AF] Seems like you’re not rising to this :-)
> I wonder whether the introduction can steal a few lines from this section
> to set the document up a bit better.
>
> *[Med] Good suggestion. Moved some text around.*
>
> In Section 6, have you invented the Filter Topology when you use
> the term "transport plane"? I think you have, and it would be
> helpful
> either:
> - to say "when we say transport plane, this is equivalent to the
>    term Filter Topology defined in RFC 9542"
> - to replace all mentions of "transport plane"
>
> I prefer the second of these.
>
> [Med] I'm not sure filtered topology is exactly identical to. I heard
> other comments that this is similar to NRP. We prefer to use a term that is
> close to what is currently used in deployments. For example, this is
> consistent with RFC9182 and several RFCs out there which include the
> following:
>
>   'underlay-transport':  Describes the preference for the transport
>      technology to carry the traffic of the VPN service.  This
>      preference is especially useful in networks with multiple domains
>      and Network-to-Network Interface (NNI) types.  The underlay
>      transport can be expressed as an abstract transport instance
>      (e.g., an identifier of a VPN+ instance, a virtual network
>      identifier, or a network slice name) or as an ordered list of the
>      actual protocols to be enabled in the network.
>
>      A rich set of protocol identifiers that can be used to refer to an
>      underlay transport are defined in [RFC9181].
>
> [AF] Two points here:
>
> 1.       If this sounds like NRPs, then you are acknowledging multiple
> NRPs, which is OK but is counter to your assertion that there is a single
> NRP in all aspects of this document.
>
> *[Med] I wasn’t saying that I agree with that NRP comment. *
>
> 2.       The quoted text from 9182 sounds exactly like filtered topology
> to me
>
> *[Med] Still this can be done using the same topology. We updated the text
> with a new text to explain the notion of “transport plane”:*
>
>
>
> *NEW:*
>
> A transport plane refers to a specific forwarding behavior between PEs in
> order to provide packet delivery that is consistent with the corresponding
> SLOs.
>
>
> 7.2.3 seems to be floating a few ways of doing things in a rather
> hypothetical way. Shouldn't you be referencing the technologies
> that enable this?
>
>
> [Med] There are many controllers out there which support such features. We
> don't want to add pointers to specific vendor implementations. However,
> that functionality is covered in 9522. Hence, this NEW text.
>
>  "This approach is similar to that described in Section 4.3.1 of
> [RFC9522]."
>
>
>
> [AF] OK. If your intention is to observe that many implementations do
> different things and that there are different ways of solving the problem,
> then I think you can say:
>
> -          Many different acceptable approaches
>
> -          Implementation choice
>
> -          For example, an implementation might…
>
> *[Med] I see Julian replied to this one.*
>
> Section 8 seems to focus on the provider network.
>
>
> [Med] Yes; hence the title "Network Slicing OAM"
>
>
>
> It's all good stuff, but your TN slice appears to go outside the provider
> network. So what about OAM for the whole TN slice?
>
>
>
> [AF] This takes us back to differentiating “network slice” and “transport
> network slice”.
>
> But my question was not about the section title being wrong. It was about
> whether there is additional consideration to be given for TN slice OAM.
>
> *[Med] The customer part of the TN slice is out of scope. I hope this is
> now clear in the updated version.*
>
>
> I am worried by the presence of Appendix B. I appreciate it being
> moved out of the body of the text, and I welcome the caveat at
> the start of the appendix, but what are we, the IETF, doing
> publishing an RFC that seeks to explain elements of the 3GPP
> architecture?
>
> - That's not our business
> - I don't see how we can get IETF consensus on it
> - I think it at the very least needs formal review and approval
> by 3GPP
>
> For me this is a sticking point. I strongly believe that this
> appendix should be removed from the document.
>
>
> [Med] The IETF published many documents in the past to describe 3GPP arch.
> We tried to remind these in that appendix:
>
>   Similar to previous versions of 3GPP mobile networks [RFC6459], a 5G
>   mobile network is split into the following four major domains
>   (Figure 34):
>
> There is some value in having this content in an appendix as it provides a
> brief overview of the arch and introduces some of jargons used in the main
> document.
>
>
>
> [AF] I doubt that we are going to reach agreement on whether there is
> value to having this content in this document (compared to a web site,
> white paper or 3gpp document).
>
> That the IETF may have published material relating to 3gpp work in the
> past is not reason to do it again.
>
> I do appreciate the careful caveat at the start of the appendix, although
> perhaps that should also be clear where the references are made. Indeed,
> section 1 says:
>
>    A brief 5G overview is provided in Appendix B for the reader's
>
>    convenience.  The reader may refer to [TS-23.501] or [_5G-Book] for
>
>                  more details about 3GPP network architectures.
>
> Perhaps this would be better as…
>
>    A brief 5G overview is provided in Appendix B for the reader's
>
>    convenience.  For a definitive description of 3GPP network
>
>    architectures, the reader should refer to [TS-23.501]. More
>
>    details can be found in [_5G-Book].
>
>
>
> *[Med] Looks good to me. Updated the draft accordingly. Thanks. *
>
>
>
>
>
> However, if the appendix is only “for the reader’s convenience” then it
> seems that it is just there so that the reader does not need to look in
> another place?
>
> I am still really concerned that we are describing 3gpp work in an IETF
> document without having it reviewed by the 3gpp. Why can’t we liaise this
> to 3gpp and ask whether it correctly reflects 3gpp’s intentions?
>
> *[Med] I leave this one to the Chairs.*
>
>
[VPB] We (chairs) find the Appendix in its current form to be useful and
would like to retain it in the version that would be submitted to IESG for
publication. We’ll let the IESG decide whether it is appropriate to keep
this Appendix in the document. We have sent out a couple of liaison
statements to 3GPP in recent months regarding our network slicing work (the
first statement did include a reference to this document). We will look to
include a note on the progress of this document in our next liaison update.

> ____________________________________________________________________________________________________________
> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>