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

[Adrian Farrel <[e-mail]>]

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/. 

 

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]>