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 <[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]<mailto:[email protected]>> On Behalf Of Uma
Chunduri
Sent: Wednesday, October 21, 2020 6:18 PM
To: dmm <[email protected]<mailto:[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 ..)
Caution (External, [email protected]<mailto:[email protected]>)
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
<[email protected]<mailto:[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
