Re: New Version Notification for draft-clt-dmm-tn-aware-mobility-07.txt

Thanks for your review, comments in-line ..

--
Uma C.

On Mon, Oct 26, 2020 at 1:15 PM Majumdar, Kausik <
[email protected]> 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 <[email protected]>; dmm <[email protected]>
> *Subject:* RE: [DMM] New Version Notification for
> draft-clt-dmm-tn-aware-mobility-07.txt
>
>
>
> Hi Uma,
>
>
>
> My comments are inline below.
>
>
>
> *From:* dmm <[email protected]> *On Behalf Of *Uma Chunduri
> *Sent:* Wednesday, October 21, 2020 6:18 PM
> *To:* dmm <[email protected]>
> *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 <
> [email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/dmm