Thanks for your review, comments in-line .. -- Uma C.
On Mon, Oct 26, 2020 at 1:15 PM Majumdar, Kausik < kausik.majum...@commscope.com> wrote: > 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. > > Sure, shall fix that. > 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? > > > Right, UDP Src port. 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? > > > That's a typo. Shall correct it. > 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? > Good catch. This was from the earlier versions and shall change this to be aligned with the rest of the content. Yes, obviously it should not use QFI anywhere.. > > > 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. > Thx. Shall fix this too (left out from earlier versions without getting updated). > > 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> *On Behalf Of *Uma Chunduri > *Sent:* Wednesday, October 21, 2020 6:18 PM > *To:* dmm <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 ..) > > > > On Wed, Oct 21, 2020 at 1:29 PM Majumdar, Kausik < > 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
