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

[Adrian Farrel <[e-mail]>]

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.


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.

 

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.

---

 

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

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?

---

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

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

Additionally, I wonder whether the idea of 1:N is real. 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?


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.

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.

2.       The quoted text from 9182 sounds exactly like filtered topology to me


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…



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.


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

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?