Hi Uma, Few more general minor comments on the draft below:
1. Section 2.2 talks about front haul but picture, can you please capture it in the figure 1. 1. Section 2.4 mentions – "The PE router inspects incoming PDU data packets for the MTNC-ID, classifies and provides the VN service provisioned across the transport network." Should PE rather inspects the UDP Src Port here which mirrors MTN-ID? 3. Section 2.7 mentions – a) “If a PE is not co-located at the UPF then mapping to the underlying TE paths at PE happens based on the encapsulated GTP-US packet as specified in Section 2.6.” Should it be GTP-U packet? b) "o If any other form of encapsulation (other than GTP-U) either on N3 or N9 corresponding QFI information MUST be there in the encapsulation header." Not very clear on this. Does it need to be there? c) "If TNF is seen as part of management plane, this real time flexibility is lost." The above statement contradicts the figure 1. We should change that to a separate management function. Regards, Kausik From: Majumdar, Kausik Sent: Monday, October 26, 2020 12:49 PM To: Uma Chunduri <umac.i...@gmail.com>; dmm <dmm@ietf.org> Subject: RE: [DMM] New Version Notification for draft-clt-dmm-tn-aware-mobility-07.txt Hi Uma, My comments are inline below. From: dmm <dmm-boun...@ietf.org<mailto:dmm-boun...@ietf.org>> On Behalf Of Uma Chunduri Sent: Wednesday, October 21, 2020 6:18 PM To: dmm <dmm@ietf.org<mailto:dmm@ietf.org>> Subject: Re: [DMM] New Version Notification for draft-clt-dmm-tn-aware-mobility-07.txt Thanks Kaushik for your comments. Need a quick clarification (see below ..) Caution (External, umac.i...@gmail.com<mailto:umac.i...@gmail.com>) Spam Content Details<https://shared.outlook.inky.com/details?id=Y29tbXNjb3BlL2thdXNpay5tYWp1bWRhckBjb21tc2NvcGUuY29tLzZhMWU2MWE2MDA2ZDBkM2ZjM2Y3ZGQ3MThmM2M5NzdmLzE2MDMzMjk1MTQuMTg=#key=907e11ca2c9278a0aa07bfcd42e9c8a7> Report This Email<https://shared.outlook.inky.com/report?id=Y29tbXNjb3BlL2thdXNpay5tYWp1bWRhckBjb21tc2NvcGUuY29tLzZhMWU2MWE2MDA2ZDBkM2ZjM2Y3ZGQ3MThmM2M5NzdmLzE2MDMzMjk1MTQuMTg=#key=907e11ca2c9278a0aa07bfcd42e9c8a7> FAQ<https://www.inky.com/banner-faq/> Protection by INKY<https://www.inky.com> Thanks Kaushik for your comments. Need a quick clarification (see below ..) On Wed, Oct 21, 2020 at 1:29 PM Majumdar, Kausik <kausik.majum...@commscope.com<mailto:kausik.majum...@commscope.com>> wrote: Hi Uma et all, Thanks for putting together this draft to describe the framework for mapping the slices in 5G mobile systems to transport slices in IP towards the UPF. This framework is valuable and we are actually looking for further extensions of the TN characteristics in non-mobility domain (SD-WAN) and that is being worked out to be submitted in RTG WG. Thanks. I would also request you to consider the Security Characteristics in addition to the current Transport Path characteristics. Preserving the security characteristics in non-mobility SD-WAN domain would be an important aspects. My suggestions would be to extend the current SST for secure traffic. As a result, it would be good if we can define additional UDP Source Port range to capture the Security characteristics for the current service types. We already described the generic case where security is applied (section 2.6), when the user plane emits the packet to transport (could be N3/N9 interfaces or S1U interface terminating at SGWs). That addresses mostly shared transport cases. If I understand correctly, you want security done by PE's before gNB/UPF?? I can imagine few usef of this but can you explain why you are looking for this option? Yes, I am looking for UE traffic to be secured by the PE’s before gNB/UPF. There could be specific traffic types for MIOT, EMBB, and URLLC service types where security is more important. Even this draft is addressing data path security for these service types the security characteristics needs to be preserved all the to the traffic destination, it can’t stop at SGWs or UPF. Then, the purpose for UE traffic to achieve end to end security is lost. Specially if we look into SD-WAN deployments the security is the key aspects and the SD-WAN Edge Nodes establish secure IPSec tunnels between them. Here https://tools.ietf.org/html/draft-dunbar-bess-bgp-sdwan-usage-08 nicely captures SD-WAN use cases for Homogeneous and Hybrid networks. Considering that, if the UE traffic needs to go beyond SGWs/UPF to the actual destination in the Data Network connected through SD-WAN Edge Nodes (Enterprise 5G case) the security characteristics for all the SSTs need to be preserved to maintain the E2E security. I think it would be good to expand the UDP Src Port range table captured in Figure 2. For all of the current SST types we could come up with different Range where E2E security is the key requirement for the UE traffic like below: UDP Src Port Range Ax – Ay : SST - MIOT with Security .. In general, if we look into the SD-WAN use cases the security is the key aspects how SD-WAN edge nodes establishes and send secure traffic between them to connect different sites branches, branch to the cloud GW. I would be happy to share more context on the use cases and discuss further on the approaches. Sure. But is this a mandatory option for your E2E use case with SD-WAN beyond mobility domain? I would say it is a mandatory option for E2E use cases with SD-WAN beyond mobility domain. If you look into the retail stores, education, etc (small to medium enterprise deployments), majority of the connections land into cloud with a secure tunnel connectivity to the cloud GW. These enterprise SD-WAN edge devices accept connections not only from wireless APs, but also for the mobility traffic through SWGs/UPF. In the case of UE mobility traffic needs to land into large enterprise with a security aspects, the SD-WAN GW in the corporate network need to preserve that behavior for E2E security. Hope it clarifies. How the SD-WAN GW map the TN characteristics in non-mobility domain to maintain UE’s E2E traffic characteristics is being worked out, and would be submitted. Regards, Kausik -- Uma C. Regards, Kausik
_______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm