[DMM] Questions and comments on draft-ietf-dmm-5g-uplane-analysis-00

[Sridhar Bhaskaran <[e-mail]>]

Dear authors of draft-ietf-dmm-5g-uplane-analysis-00,

Thank you for the draft.

I have the following questions for clarification and comments on draft-ietf-dmm-5g-uplane-analysis-00

Questions
========
1. Section 3.6 - could you elaborate on what you mean by

>>[GTP-U-6]:  Does not support to response ICMP PTB for Path MTU
               Discovery.

2. Section 4.1

>>These tunnels are available to be handled by other
   authorized functions through the control plane.

Could you elaborate on what you mean by "other" authorized functions? Right now only SMF is allows to setup / teardown tunnels via N4 at UPF.

3. Section 4.2 Arch-Req-3: Could you please clarify the following sentence? First part of sentence talks about multiple PDU sessions but end of the sentence talks about one PDU session. So its not clear to me which case this is talking about.

However
   it should be the multiple PDU sessions multihoming case where the
   destination gNB or UPF needs to maintain multiple tunnel states under
   the one PDU session to one UP tunnel architectural principle.


4. Section 4.2 - Arch-Req-5. I am not able to understand the following sentences. Could you clarify what you mean by "connecting them without extra anchor points"? Also what does "them" refer to here? Does it refer to UE or UPF?

In addition, deployment of multiple UPFs as anchors closed to UEs'
   site and connecting them without extra anchor points enable to make
   data path more efficient.


5. Section Arch-Req-5: Are the following statements an architectural requirement derived from 23.501 or an architectural requirement this draft is putting on 3GPP? Atleast the words " UP protocol shall support to aggregate several PDU sessions into a tunnel or shall be a session-less tunnel." Seems like this draft is putting a requirement on 3GPP.

It is expected that multiple UPFs with per session tunnel handling
   for a PDU session becomes complicated task more and more for a SMF by
   increasing number of UPFs, and UP protocol shall support to aggregate
   several PDU sessions into a tunnel or shall be a session-less tunnel.

Comments:
==========
1. Section 4.1.1 - traffic detection based on UE IP address and SDF filters is missing in the below list

o  For IPv4 or IPv6 PDU Session type

      *  PDU Session

      *  QFI

      *  Application Identifier: The Application ID is an index to a set
         of application detection rules configured in UPF

2. Section 4.2 Arch-Req-2:

>> The 5G system requires IP connectivity for N3, N6, and N9 interfaces.

There is a specific case where IP connectivity on N6 is not mandatory. For Ethernet PDU sessions, the anchor UPF could use L2 switching on N6 side. You refer clause 5.6.10.2 of TS 23.501 especially the statements below

-	Configurations, where more than one PDU Session to the same DNN (e.g. for more than one UE) corresponds to the same N6 interface. In this case the UPF acting as PSA needs to be aware of MAC addresses used by the UE in the PDU Session in order to map down-link Ethernet frames received over N6 to the appropriate PDU Session. Forwarding behaviour of the UPF acting as PSA is managed by SMF as specified in clause 5.8.2.5.


3. Section 4.2 Arch-Req-3:

Multihoming is provided with Branching Point (BP) or Uplink
   Classifier (UL CL) which are functionalities of UPF.

ULCL is not used for multihoming. ULCL is used for traffic splitting towards a local DN. Only BP is used for multihoming case.

4. Section 5 is missing one evaluation aspect. GTP-U supports "End markers" to help RAN sequence the packets when there is a change of UPF during mobility procedures. So any user plane protocol that is to be evaluated need to support some mechanism to help the last downlink node on path (e.g gNB) to sequence the packets coming from multiple UPFs during mobility cases.

5. Section 5.7 - Need justification for the following statement:

However some means need to indicate a slice on the shared
   underlying networks of the UP over the wire.

What is broken or what is the issue if slice for transport is not indicated on the UP over the wire? What are the issues with providing a "network instance" (which could be mapped to a transport path) in the forwarding action rule of a PDU session?

What are the advantages of carrying slice information in every packet?

Regards
Sridhar Bhaskaran