Re: [DMM] questions and comments to draft-ietf-dmm-tn-aware-mobility-07

Sridhar,

Thanks for the answers to my questions. Based your answers, I have some suggestion to make the draft clearer.

See below:

From: Sridhar Bhaskaran <sridhar.bhaskaran@gmail.com>
Sent: Wednesday, September 6, 2023 10:26 AM
To: Linda Dunbar <linda.dunbar@futurewei.com>
Cc: dmm@ietf.org; draft-ietf-dmm-tn-aware-mobility@ietf.org
Subject: Re: [DMM] questions and comments to draft-ietf-dmm-tn-aware-mobility-07

Hi Linda,

Thank you for the comments and questions. I am providing below my answers inline with tag [SB] as a co-author

On Sat, Sep 2, 2023 at 8:07 AM Linda Dunbar <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>> wrote:
Uma, John, Sridhar, Jeff, and Praveen,

draft-ietf-dmm-tn-aware-mobility-07 has very good description of 5G system and 5G slices mapping to transport network VPNs.

I have some questions and comments:

  *   Section 3.1:
There are data plane traffic (i.e. UE<-> service instance in DC) and Control Plane traffic (UE<->gNB<-> 5G functions). Is the 5G End-to-End network slicing for the control plane and data plane?
[SB] It is for both. In the control plane, slice specific isolated control functions (SMF, PCF, NRF, NSSF etc) are selected during UE registration procedure as specified in 3GPP TS 23.501. The AMF remains common for a set of slices. In view of the ability to select separate and distinct instances for these control plane functions, it is possible to assign control plane interface IPs to these functions from different IP pools. It is possible to engineer the IP transport networks for different slice requirements based on these IP pool differentiations.
In the user plane, entropy is built into each packet to identify the slice it belongs. One of the suggested methods in this draft is to use the UDP source port.

[Linda] it would be clearer to have separate sections for Control Plan traffic and data plane traffic as the Control plane traffic is End-to-End within the 3GPP domain,  whereas the user traffic between gNB<->UPF is not End-to-End.

For the data plane traffic, the End-to-End network sliding should continue from UPFs to the service destination (which could be VMs in data center).
[SB] UPF to service destination path is outside the scope of 3GPP. Any IETF based mechanism can be used here for slicing (e.g. Service function chaining, SRv6, SR-MPLS etc)

[Linda] You are correct. There is a draft to extend your proposed mechanism from UPFs to the service Destination: https://datatracker.ietf.org/doc/draft-mcd-rtgwg-extension-tn-aware-mobility/

  *   Section3.2:
Fronthaul network is very time sensitive. So must have very few links (hops) from IP perspective. Do you see applicability of TE in the Fronthaul network?

[SB] This section also talks about L2 network for fronthaul. In fact for the fronthaul eCPRI over Ethernet is more common than eCPRI over IP.  The following statement clearly mentions that the provisioned capabilities shall take into account overall delay budget

“The provisioned slice
   capabilities in the fronthaul transport network MUST take care of the
   latency and jitter budgets of the specific slice for the fronthaul interface”

So this could imply reducing the number of hops. Actually IETF need not be prescriptive here. The key thing is the overall delay budget shall be met (for e.g. if the fronthaul delay budget is 100 microseconds then irrespective of number of hops this budget shall be met).
[Linda] Thanks for the details. Can you add those text to your draft?

  *   Section 4: it would be clearer to emphasize that the transport network is really among 5G functions. So, from data plane perspective, the End-to-End transport has to traverse the IP network between the UPFs and the service destinations.

 [SB] This is a good comment. We can consider revising the text to emphasize this in the next revision.
Thank you
Linda
Thank you.
Linda Dunbar

_______________________________________________
dmm mailing list
dmm@ietf.org<mailto:dmm@ietf.org>
https://www.ietf.org/mailman/listinfo/dmm

--
 o__
 _>  /__
(_) \(_)... Burn fat not fuel - Bike along to a healthier life and cleaner
world! :)

Sridhar Bhaskaran