Re: [DMM] New Version Notification for draft-clt-dmm-tn-aware-mobility-07.txt
Uma Chunduri <umac.ietf@gmail.com> Tue, 27 October 2020 00:30 UTC
Return-Path: <umac.ietf@gmail.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3513A1116 for <dmm@ietfa.amsl.com>; Mon, 26 Oct 2020 17:30:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQC4voO_iTcI for <dmm@ietfa.amsl.com>; Mon, 26 Oct 2020 17:30:07 -0700 (PDT)
Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B2033A1115 for <dmm@ietf.org>; Mon, 26 Oct 2020 17:30:06 -0700 (PDT)
Received: by mail-ua1-x934.google.com with SMTP id r9so3451151uat.12 for <dmm@ietf.org>; Mon, 26 Oct 2020 17:30:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+cRaOIZmy0Ly8YgtYleHcBFSUJGOEbY6AsHLOgfrNHc=; b=tZLF3o3i+swO3Dj56QoVSKBLxBSlTouwA5cvxI5hbGLXG+P7mT8TNhpuIpE+ycdz9f qMRooao0SWrWHMrJSGpYmoeYoZlSOnRg3hHjBfgK8k0mGLDulb4HYFStPq6IoGj3LsJH RS66erEoYzgVr+5VtIQUbb5QyhgBCdybZG3H4MmHj3Wj9RTSzxbX95+dExKdu+VJpO+7 hC49TUoumqGKkKObTTxqqicv1U3h2PmyMsnsd1N4dyUqVBwrLaiB/1pXyXcGVfWuBveh S99olBtwHHaG1SitxTJMTGjxWFQfIsSJMuf8CyfkMz4QDFlLLi51axyXw92aGMO7ktCI PZnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+cRaOIZmy0Ly8YgtYleHcBFSUJGOEbY6AsHLOgfrNHc=; b=FwZfqW8u8Kk0MiyyiXDGLlm1kE8j7SFdoFCLsjIrAE6RZJDSJwNk9uS5xz2ESr6ZEe IYtVLUX72+2Q1u6/zrMeTsKOHPNM7GsZj3GVpH+17tLq3lY6hCTYhUY/72dHSSjC2mP0 ZGgHxJG1aEqlSBKp3ubiOCyddLv7wZ9TR1vGusYpayDEs1R/rr/umXAJGENfO8NaP5uQ bFfdYdyHbs3y58CAqTO4yG6sGZQRQWBaSbBKN/Euwh23FYjGReb78o6gsFucE54B+dHk lDZ7D/SKKHoJ6K19oB5Xf5+2a0Ckv3kFjn+ACmiQsZp2VY9JHi3Gg7N+BhBnsixVM8X1 JPXg==
X-Gm-Message-State: AOAM533/ROn0uX3zyOw1nVFvM+hlvOfpYbPnKSHJkcxlh66/b4QzmaUI bBjrbS7Z1y966iK2b/qBS2t+vIZuUnHTclwgkQ0=
X-Google-Smtp-Source: ABdhPJzYpOn4paOl6ziaVpR4Q6AkBSEW45VfB39Wkv+/Ny2Z36IaRBRfc8qmyeHfh/9ZkGlMc/trrx5l1ALXj6mGB8Y=
X-Received: by 2002:ab0:45a2:: with SMTP id u31mr11183596uau.126.1603758605950; Mon, 26 Oct 2020 17:30:05 -0700 (PDT)
MIME-Version: 1.0
References: <160133669315.20579.1349579162555966845@ietfa.amsl.com> <CAF18ct6U17CJ2_ijgKES2Rd9CqgxzwBAectqH6EhNtXUyA83ng@mail.gmail.com> <34BB0DFC-FACD-4D09-A4E1-791E41B25748@cisco.com> <BY5PR14MB41453099EB0C7E637CA411C4FA1C0@BY5PR14MB4145.namprd14.prod.outlook.com> <CAF18ct5T3_6PFKPRCa=+gEUSqYeJEOKQPz-MEYYfg5ZzExZRog@mail.gmail.com> <BY5PR14MB4145F71E0C515219EE1DA479FA190@BY5PR14MB4145.namprd14.prod.outlook.com> <BY5PR14MB4145344108B23C698035DD3FFA190@BY5PR14MB4145.namprd14.prod.outlook.com>
In-Reply-To: <BY5PR14MB4145344108B23C698035DD3FFA190@BY5PR14MB4145.namprd14.prod.outlook.com>
From: Uma Chunduri <umac.ietf@gmail.com>
Date: Mon, 26 Oct 2020 17:30:08 -0700
Message-ID: <CAF18ct5=eA6k4PwVnbZMTas8AXbb9ZdKFaeRih1jahKsER94og@mail.gmail.com>
To: "Majumdar, Kausik" <Kausik.Majumdar@commscope.com>
Cc: dmm <dmm@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000003632605b29c2658"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/RZDLrahKQ-3rHOUosZUHZYBqPC0>
Subject: Re: [DMM] New Version Notification for draft-clt-dmm-tn-aware-mobility-07.txt
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Oct 2020 00:30:11 -0000
Thanks for your review, comments in-line .. -- Uma C. On Mon, Oct 26, 2020 at 1:15 PM Majumdar, Kausik < Kausik.Majumdar@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.ietf@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-bounces@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.Majumdar@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 > > > >
- Re: [DMM] New Version Notification for draft-clt-… Uma Chunduri
- Re: [DMM] New Version Notification for draft-clt-… Sri Gundavelli (sgundave)
- Re: [DMM] New Version Notification for draft-clt-… Pablo Camarillo (pcamaril)
- Re: [DMM] New Version Notification for draft-clt-… Majumdar, Kausik
- Re: [DMM] New Version Notification for draft-clt-… Joel M. Halpern
- Re: [DMM] New Version Notification for draft-clt-… Uma Chunduri
- Re: [DMM] New Version Notification for draft-clt-… Uma Chunduri
- Re: [DMM] New Version Notification for draft-clt-… Uma Chunduri
- Re: [DMM] New Version Notification for draft-clt-… Majumdar, Kausik
- Re: [DMM] New Version Notification for draft-clt-… Majumdar, Kausik
- Re: [DMM] New Version Notification for draft-clt-… Uma Chunduri
- Re: [DMM] New Version Notification for draft-clt-… Uma Chunduri