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

[Loa Andersson <[e-mail]>]

WG, chairs,

I agree with Adrian. We should be very careful with our relationships 
with other SDOs. Communicating to other SDOs what we are doing is a
corner stone in maintain good relationships with other SDO, to this end
please send the liaison Adrian is suggesting.

Or maybe even better remove the appendix.

/Loa

On 2024-05-15 23:04, Adrian Farrel wrote:
> Well, I was not asking for the document to be parked. I was really 
> hoping that the appendix would be removed.
> 
> If you judge the conversation on the list (I say I don’t like it, two of 
> the authors say they want to keep it) as indicating consensus to retain 
> it, then I wouldn’t want to argue with you (mainly because the topic is 
> not important enough to fight you on what seems to be pretty shaky 
> grounds for declaring consensus).
> 
> Can I suggest that, if you think about this a bit, you might note that 
> the pipeline from now to RFC publication is relatively long, and if you 
> sent a liaison today, requesting 3GPP review and asking for objections 
> formally as a liaison or informally on our mailing list, from anyone who 
> thinks the appendix may misrepresent 3GPP’s work then you are probably 
> giving enough lead time to fix any issues. OTOH, if you leave it until 
> this reaches IESG telechat review, you risk delaying the document in 
> exactly the way you suggest I might be implying.
> 
> Ciao,
> 
> Adrian
> 
> *From:*Vishnu Pavan Beeram <[e-mail]>
> *Sent:* 15 May 2024 13:10
> *To:* [e-mail]
> *Cc:* [e-mail]; Krzysztof Szarkowicz 
> <[e-mail]>; TEAS WG <[e-mail]>; TEAS WG Chairs 
> <[e-mail]>; [e-mail]
> *Subject:* [Teas] Re: Late WGLC review of draft-ietf-teas-5g-ns-ip-mpls
> 
> Adrian,
> 
> Thanks for trying to make sure the WG is doing the right thing.
> 
> Your core point is process-oriented (not technical). Your suggestion 
> implies parking the document until we get some official feedback from 
> 3GPP on whether the overview of the 3GPP architecture in the Appendix of 
> this informational document is accurate or not.
> 
> As noted in the previous email, the chairs’ call on this point (based on 
> the discussion on this thread) is to defer it to IESG to make this 
> process decision. We’ll document this as an open question and reference 
> the thread in the Shepherd’s write-up.
> 
> Regards,
> 
> -Pavan, Lou and Oscar
> 
> On Wed, May 15, 2024 at 1:08 PM Adrian Farrel <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     Hi Pavan,
> 
>     Oh dear, this is going to sound pissy. Sorry about that, but I am
>     just trying to make sure the WG does the right thing.
> 
>     > [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.
> 
>     Is that you calling consensus on the issue, or adding your voices to
>     the debate?
> 
>     If the former, well, that’s what you’re there for although the
>     discussion on the list seems to have been limited.
> 
>     If the latter, then I **do** hear your opinion, but I wonder what it
>     is founded on: what is it about this appendix that you find useful?
> 
>     > 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. 
> 
>     That is really not the same thing as asking them to verify and
>     confirm that the content of this appendix accurately reflects the
>     material in their standards.
> 
>     Why is this not the case?
> 
>     Suppose, for example, that an SDO sent the IETF a liaison “for
>     information” saying “We are working on developing a standard related
>     to MPLS” and then, six months later, published a specification that
>     seriously misinterpreted the MPLS architecture and recommended an
>     approach that was not compatible with the work of the IETF. Would we
>     say “Oh well, our mistake, we should have reviewed it when they sent
>     us a copy,” or would we be upset?
> 
>     Cheers,
> 
>     Adrian
> 
>     *From:*Vishnu Pavan Beeram <[e-mail]
>     <mailto:[e-mail]>>
>     *Sent:* 14 May 2024 20:20
>     *To:* [e-mail] <mailto:[e-mail]>
>     *Cc:* [e-mail] <mailto:[e-mail]>; Krzysztof
>     Szarkowicz <[e-mail]
>     <mailto:[e-mail]>>; TEAS WG <[e-mail]
>     <mailto:[e-mail]>>; TEAS WG Chairs <[e-mail]
>     <mailto:[e-mail]>>;
>     [e-mail]
>     <mailto:[e-mail]>
>     *Subject:* [Teas] Re: Late WGLC review of draft-ietf-teas-5g-ns-ip-mpls
> 
>     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]
>     <mailto:[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/ <https://datatracker.ietf.org/doc/draft-ietf-teas-5g-ns-ip-mpls/06/>.
> 
>         Please see inline.
> 
>         Cheers,
> 
>         Med
> 
>         *De :*Adrian Farrel <[e-mail]
>         <mailto:[e-mail]>>
>         *Envoyé :* jeudi 9 mai 2024 11:25
>         *À :* 'Krzysztof Szarkowicz' <[e-mail]
>         <mailto:[e-mail]>>
>         *Cc :* 'TEAS WG' <[e-mail] <mailto:[e-mail]>>; 'TEAS
>         WG Chairs' <[e-mail] <mailto:[e-mail]>>;
>         [e-mail]
>         <mailto:[e-mail]>; BOUCADAIR
>         Mohamed INNOV/NET <[e-mail]
>         <mailto:[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] <mailto:[e-mail]>
>         To unsubscribe send an email to [e-mail]
>         <mailto:[e-mail]>
> 
> 
> _______________________________________________
> Teas mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]