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 <[email protected]> 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. 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) > > - 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). > > - 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 Dunbar > > > > _______________________________________________ > dmm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmm > -- o__ _> /__ (_) \(_)... Burn fat not fuel - Bike along to a healthier life and cleaner world! :) Sridhar Bhaskaran
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
