From nobody Mon Feb 1 09:39:38 2021 Return-Path: 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 1F5693A1340 for ; Mon, 1 Feb 2021 09:39:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 d_sQfyecK35e for ; Mon, 1 Feb 2021 09:39:33 -0800 (PST) Received: from mail2.frequentis.com (mail2.frequentis.com [195.20.158.51]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BE743A12E7 for ; Mon, 1 Feb 2021 09:39:31 -0800 (PST) X-IronPort-AV: E=Sophos; i="5.79,393,1602540000"; d="scan'208,217"; a="10342240" Received: from frqat01nt72.frequentis.frq ([172.16.1.72]) by mail2.frequentis.com with ESMTP; 01 Feb 2021 18:39:29 +0100 From: VARKONYI Bela To: "dmm@ietf.org" Thread-Topic: Mail regarding draft-ietf-dmm-mag-multihoming Thread-Index: Adb4wIsu9PSIA2d5Q1u0hhE3V7AZLw== Date: Mon, 1 Feb 2021 17:39:29 +0000 Message-ID: <952de06bf40a4e13b518ca7f6d25bdd8@frequentis.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_50bef7d4-e22d-4ab7-80f8-95d0deb51eea_Enabled=true; MSIP_Label_50bef7d4-e22d-4ab7-80f8-95d0deb51eea_SetDate=2021-02-01T17:39:27Z; MSIP_Label_50bef7d4-e22d-4ab7-80f8-95d0deb51eea_Method=Standard; MSIP_Label_50bef7d4-e22d-4ab7-80f8-95d0deb51eea_Name=Frequentis General; MSIP_Label_50bef7d4-e22d-4ab7-80f8-95d0deb51eea_SiteId=4a636d6a-7c5d-4373-a76b-698cfd77431f; MSIP_Label_50bef7d4-e22d-4ab7-80f8-95d0deb51eea_ActionId=f3dc0aaa-9e81-4f3e-9787-79dbaa4b8bc4; MSIP_Label_50bef7d4-e22d-4ab7-80f8-95d0deb51eea_ContentBits=0 frequentis_classification_level: Frequentis General x-originating-ip: [192.168.254.170] Content-Type: multipart/alternative; boundary="_000_952de06bf40a4e13b518ca7f6d25bdd8frequentiscom_" MIME-Version: 1.0 Archived-At: Subject: [DMM] Mail regarding draft-ietf-dmm-mag-multihoming X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2021 17:39:35 -0000 --_000_952de06bf40a4e13b518ca7f6d25bdd8frequentiscom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Colleagues, RFC 8278 has a major error. The MAG is a ground element that is connected with the LMA typically by fix= ed networks (fiber optics or terrestrial microwave networks, but not LTE or= WAN). The end system flows are not connected to the MAG directly, since the MAG i= s on the ground, fixed and not moving, but rather to the mobile router (MR)= . Then the MR and the MAG is connected by wireless networks such as LTE or WL= AN. The authors has mixed up the MR and MAG roles, and put the MAG unto the mov= ing platform that is incorrect. This whole standard is basically broken and it should be withdrawn and repl= aced by a correct standard. Best regards, Bela ---------------------------------------------------------------------------= --------- Bela VARKONYI ATM Network Solutions / Chief Network Architect FREQUENTIS AG Innovationsstr. 1., A-1100 Wien, Austria Mobile: +43 664 608501351 Email: bela.varkonyi@frequentis.com Web: www.frequentis.com Handelsgericht Wien (Vienna Commercial Court): FN 72115b DVR 0364797, ATU 14715600 ---------------------------------------------------------------------------= --------- --_000_952de06bf40a4e13b518ca7f6d25bdd8frequentiscom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Colleagues,

 

RFC 8278 has a major error.

 

The MAG is a ground element that is connected with t= he LMA typically by fixed networks (fiber optics or terrestrial microwave n= etworks, but not LTE or WAN).

The end system flows are not connected to the MAG di= rectly, since the MAG is on the ground, fixed and not moving, but rather to= the mobile router (MR).

Then the MR and the MAG is connected by wireless net= works such as LTE or WLAN.

 

The authors has mixed up the MR and MAG roles, and p= ut the MAG unto the moving platform that is incorrect.

This whole standard is basically broken and it shoul= d be withdrawn and replaced by a correct standard.

 

 

Best regards,

Bela

 

----------------------------------------------------------= --------------------------

Bela VARKONYI

ATM Network Solutions / Chief Network Architect

FREQUENTIS AG

Innovationsstr. 1.,  A-1100 Wien, Austria<= /span>

Mobile: +43 664 608501351

Email: bela.varkonyi@frequentis.co= m

Web: www.frequentis.com

 

Handelsgericht Wien (Vienna Commercial Court): FN 72115b

DVR 0364797, ATU 14715600

----------------------------------------------------------= --------------------------

 

 

--_000_952de06bf40a4e13b518ca7f6d25bdd8frequentiscom_-- From nobody Mon Feb 1 16:08:05 2021 Return-Path: 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 BE6633A15DE for ; Mon, 1 Feb 2021 16:08:03 -0800 (PST) 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 GYBpvAt_NFfH for ; Mon, 1 Feb 2021 16:08:02 -0800 (PST) Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (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 033903A15D9 for ; Mon, 1 Feb 2021 16:08:01 -0800 (PST) Received: by mail-yb1-xb2c.google.com with SMTP id w204so15878142ybg.2 for ; Mon, 01 Feb 2021 16:08:01 -0800 (PST) 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; bh=jrGaRLMsII+KoB1hpqPatrgAIZQd2g6hzhusnF3d7VE=; b=XRwZh3ygzrV2Ugc1Jw4q7AG0JUmvTNExxyf9+esTgHHYszWsGdOzXN11QSj5wWy4do 1xmoSmsv8y+W1gSwdct/vG03/lGQrz73UUICvNW4SEx6ukeVoBO78l7FwNiIdy475nAD 4Vqwv6fNnPxJB6iypmsr7nBsJ66jBgNrAorJyfKnTxczOlsIANcTtSSmto9cgIWEqkRq DgShwjBUUsNxCA4c3kI4WxGoVGl3YMTa5v0wgy4rDNEYlPMglnyM0sW3qDrpY/9Q4jBY orHeuiD2oFVmglp1feFL8bzySiIFD+i6VBpObo1pmwBV4sVG2rlWg5Sv7ODQnecsv2fV jOMg== 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; bh=jrGaRLMsII+KoB1hpqPatrgAIZQd2g6hzhusnF3d7VE=; b=H7RGVhPJDDqYXu9w+pQNrOGa9GQHU65BmEJqeycAcZMN5sHTohx71Q+xo7m6cDKgTn 5DPGf/txe2gutQSKImCUQIp7uguMz25sD91/cPq0ZpKV87Q8J7OHQpCsvxy2nIJ42kpG dsdlbijgMb9rcFF3xTxhxp/Sqy9CTh/Nt/gFzX9eJW0g8d7ZNnvmmkcte/UASLz10zWH rJlOXlJXluB6YmiuMAmjLyJ9LDCHQIZtkQnk2XaDyMa0qJLqPBgcYifetXyGx6ERof6Y 61xp08cZLnKxnRIsx3WdPwnts9aVrCtDmkZEHBwaaLsg59+AGRrLSAZVYVjiwQr2jtlr HxmQ== X-Gm-Message-State: AOAM532pAP+EiaqVGaKyQc2s8TdszvA1iqwWfs+m+La4TOXC/pYk1Avn WrSSw+eDodxGm/4lP1ZEfhqS4pTTaV4akaXLg7HLILjF X-Google-Smtp-Source: ABdhPJyeh8ogkhqdN7u68uI+OjxHLgOaIHpv/fMxeFQJo/Z8GJ/qKMvZPRUXj1OO9kLjH/qSoLKqrLiN75SBmxE/LDs= X-Received: by 2002:a05:6902:1025:: with SMTP id x5mr27862203ybt.21.1612224481026; Mon, 01 Feb 2021 16:08:01 -0800 (PST) MIME-Version: 1.0 References: <96ffc11c-a823-19ca-3039-7881f60dd9c6@joelhalpern.com> <198e4e59-a9e8-6f46-e4f0-6558ae1f909e@joelhalpern.com> <159c549a-7e17-f741-0307-dee73dbeeb9e@joelhalpern.com> In-Reply-To: <159c549a-7e17-f741-0307-dee73dbeeb9e@joelhalpern.com> From: Uma Chunduri Date: Mon, 1 Feb 2021 16:07:50 -0800 Message-ID: To: dmm Content-Type: multipart/alternative; boundary="0000000000007d648405ba4f43dd" Archived-At: Subject: Re: [DMM] Call for adoption of draft-clt-dmm-tn-aware-mobility-08 as a WG document - Objections X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2021 00:08:04 -0000 --0000000000007d648405ba4f43dd Content-Type: text/plain; charset="UTF-8" Dear All, As suggested by WG chairs, we would like to spin one more version to address the comments during the adoption call and in that process will reach out to Joel and Hannu (separately) for specific inputs where terminology alignment has to happen w.r.t TEAS slicing definition draft. Will keep you updated on the WG soon. -- Uma C. On Wed, Jan 6, 2021 at 2:40 PM Joel M. Halpern wrote: > In line, > Joel > > On 1/6/2021 5:29 PM, Kaippallimalil John wrote: > > Joel, > > This draft is not attempting to lay out a new architecture. The figure > and architecture section are there to provide context for the reader. > > > > The draft is also not asserting that these are the only ways to solve > the issue. > > The last portion of the draft only refers to applicability since several > IETF technology (and even non IETF data plane like L2) may be used E2E in > the transport underlay corresponding to a 3GPP overlay (F1/W1, N3, N9). > > The draft is agnostic to any specific underlay. It is concerned with how > the slice type/QoS properties between 3GPP provider and subscriber (UE) is > realized as the data plane GTP packets (overlay) traverse one or more > transport underlay segments on path. > > At the veyr least, the draft needs significant rewording so taht it > clealry explains what you are saying here. As currently worded, it does > not lead the reader to that understanding. And as such, calls into > doubt what the supporters of adoption believe they are adopting. > > > > > The dmm working group seems to be a natural choice as folks there have > background and expertise in both IETF and 3GPP technologies. > > A WG looking like "the natural place" for something does not mean that > said working group actually has the given work in its charter. For > example, there were quite a number of drafts which were presented in the > SFC WG as the natural place for initial discussion, but which did not > fit within the SFC charter and therefore were not adopted by SFC as work > items. > > > > > Best Regards, > > John > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > --0000000000007d648405ba4f43dd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,

As suggested by WG chairs, we= would like to spin one more version to address the comments during the ado= ption call and in that process will reach out to Joel and Hannu (separately= )=C2=A0 for specific inputs where terminology alignment has to happen w.r.t= TEAS slicing definition draft.

Will keep=C2=A0you= updated on the WG soon.
--
Uma C.

On Wed, Jan 6, = 2021 at 2:40 PM Joel M. Halpern <= jmh@joelhalpern.com> wrote:
In line,
Joel

On 1/6/2021 5:29 PM, Kaippallimalil John wrote:
> Joel,
> This draft is not attempting to lay out a new architecture. The figure= and architecture section are there to provide context for the reader.
>
> The draft is also not asserting that these are the only ways to solve = the issue.
> The last portion of the draft only refers to applicability since sever= al IETF technology (and even non IETF data plane like L2) may be used E2E i= n the transport underlay corresponding to a 3GPP overlay (F1/W1, N3, N9). > The draft is agnostic to any specific underlay. It is concerned with h= ow the slice type/QoS properties between 3GPP provider and subscriber (UE) = is realized as the data plane GTP packets (overlay) traverse one or more tr= ansport underlay segments on path.

At the veyr least, the draft needs significant rewording so taht it
clealry explains what you are saying here.=C2=A0 As currently worded, it do= es
not lead the reader to that understanding.=C2=A0 And as such, calls into doubt what the supporters of adoption believe they are adopting.

>
> The dmm working group seems to be a natural choice as folks there have= background and expertise in both IETF and 3GPP technologies.

A WG looking like "the natural place" for something does not mean= that
said working group actually has the given work in its charter. For
example, there were quite a number of drafts which were presented in the SFC WG as the natural place for initial discussion, but which did not
fit within the SFC charter and therefore were not adopted by SFC as work items.

>
> Best Regards,
> John

_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
--0000000000007d648405ba4f43dd-- From nobody Mon Feb 1 16:40:28 2021 Return-Path: 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 ECB7C3A1603; Mon, 1 Feb 2021 16:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DIET_1=0.001, 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, HTTPS_HTTP_MISMATCH=0.1, 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 m0dEI4hKKynQ; Mon, 1 Feb 2021 16:40:24 -0800 (PST) Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) (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 D5B423A159D; Mon, 1 Feb 2021 16:40:23 -0800 (PST) Received: by mail-yb1-xb30.google.com with SMTP id i71so5230447ybg.7; Mon, 01 Feb 2021 16:40:23 -0800 (PST) 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=7e1hbGw9KZD5YtsYQmG8ZN35os5aMlEgCc/CSc5A3D0=; b=r3YJuJ3Naqm1V+DVd47Pnz67A41GC5n5moGVN5a2w66HnhYiQ4j+wR5f9m4A2LNUzB O9d/oBcMayQz4MixGaP1Zy+hC/5vOexzi7IavfpwpU24/pOOB5XdeFdX48qGarbX6PYH R1icTMoTivv0JvBTRfykPdOgH1iO7f87zAG6Br2PWXL/4krpk93WW2913Y6iNVwGWLU+ HcTv37DhDg46qahhvBlFQtaXRSYCA9WweT4sYKf78sWgppuHPYW/xiZo+PuJ5twjGTVw IGsN8pFaZ+DPun5oVLj6bsorOgizVD3ERnBTtK0jqFH713HLNlu/cDqSnxM3BJ0EKcVH X54g== 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=7e1hbGw9KZD5YtsYQmG8ZN35os5aMlEgCc/CSc5A3D0=; b=cRaIvaa8YX/lVh9h9Y0WSnnX8GykGpJpitUjh24DidiQFxqvph5nFjGx3BdWkmxscT mccKHxo7/i34vwP0Gg0uAHrIZNOOgrPWVJ6fBZpv5jY4VWcmnxfaDXA+3Ub+EdsMtQHv Ce48np/pmxPpL+M6G09/h+5XEM8Yt34NI1NqI2qpOdHtud8JVXyt/mb37q2kuqHmmknl vcrK70KCuXKIlxI+flVmKXMNp4OIJ15qLF0ognWeNLepp9t+KpLBhIftE51HQ08rP4vt KHPJhMYrM7h0DwtgwjwnO1jo3+3Nq8qIMNHCIvbOrchDH8Nzky9Hc7xj7CXvALI8ZjEX fIuw== X-Gm-Message-State: AOAM530lgcGvUTBO5h2xXIoPufmTLuPYdIHbv68Lt8oW8itXe5sbjKBO r9jXYeu8SA2cEThSOdsOpopPMAkEMXD+YYhOxA0= X-Google-Smtp-Source: ABdhPJxjx6OKL4fDhZZOrH1Z/WzAZgzgOHO91tKWS7FUFhbsLVEB0YkbB2/q3eFUyPzjgWsXzrsj+S7tgRSSnvYKBAs= X-Received: by 2002:a25:3104:: with SMTP id x4mr28871472ybx.141.1612226422925; Mon, 01 Feb 2021 16:40:22 -0800 (PST) MIME-Version: 1.0 References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D939966D9@DGGEMM532-MBX.china.huawei.com> <1fe994365b33407984374f4cdd224911@huawei.com> In-Reply-To: From: Uma Chunduri Date: Mon, 1 Feb 2021 16:40:11 -0800 Message-ID: To: Sridhar Bhaskaran Cc: "Gengxuesong (Geng Xuesong)" , "apn@ietf.org" , Kaippallimalil John , dmm , Lizhenbin Content-Type: multipart/alternative; boundary="0000000000003c6d2305ba4fb778" Archived-At: Subject: Re: [DMM] [Apn] Regarding APN Usecase in Mobile Core X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2021 00:40:27 -0000 --0000000000003c6d2305ba4fb778 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Sridhar, Xuesong, Quick thoughts below [Uma]: -- Uma C. On Sun, Jan 31, 2021 at 8:42 PM Sridhar Bhaskaran < sridhar.bhaskaran@gmail.com> wrote: > Hi Gengxuesong, > > On, > > >> Maybe the existing question becomes whether DSCP is sufficient for > passing information from the mobile network to transport network? whether > there is any simplification or omission of information in the mapping to > the DSCP? > [Uma]: First of all, a lot of discussion below was discussed during 04 version of https://tools.ietf.org/html/draft-clt-dmm-tn-aware-mobility-08. It was presented by John in one the IETF DMM sessions that time. And yes, it was limiting and moreover a lot of implementations reset DSCP bits in the shared transport scenarios (like WAN scenario). > > > 3GPP allows mapping of a GTP-u tunnel (PDU session) to an index to a > transport network configuration / policy via "Network Instance" concept. > When the GTP-u tunnel is setup in the UPF by the signalling plane, it > provides a "Network Instance" which is just a string that acts as an inde= x > into UPF's transport layer configuration. > [Uma]: Right and that's natural as overlay is processed at the tunnel endpoints (gNB/PSA-UPF/ULCL-UPF/BP-UPF). > Now what the transport layer configuration is - 3GPP doesn't care as it i= s > out of their remit. If you are using just plain IP routing, then DSCP (fo= r > IPv4) and Flow label (IPv6) are the options to map a QFI within a GTP-u > tunnel to IP transport. However if you are using - say a source routing > technology like SRv6, you may potentially configure the UPF to map a slic= e > (PDU session / TEID) and QFI to a specific SID list. If you use PPR > (Preferred path routing), then MTCN-ID is an option. > [Uma]: I am afraid this may not be possible in all scenarios for example gNB may not be knowing the all underlying transport information to encode that way. However, if 5G-AN node is integrated with the PE this is a possibility. Another possibility is SRv6 user plane where interoperability scenarios and overall user plane are described in https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-09 > > Also note that on the N3 interface between UPF and gNB, if it is going to > traverse a public network, operators would employ IPSec tunneling for > security. So any markings at the transport protocol layer (e.g. UDP sourc= e > port) will not be visible to on path routers due to IPSec. In such a case= , > the mapping of Slice (PDU Session / TEID) and QFI should be to the outer = IP > header in the IPSec tunnel. This is where a solution at IP header level > helps (e.g DSCP / flow label / SID list) > [Uma]: Or one can use https://tools.ietf.org/html/draft-xu-ipsecme-esp-in-udp-lb-07 (note RFC 3948 UDP encap only for nat traversal scenarios) > > Regards > Sridhar > > On Mon, Feb 1, 2021 at 8:10 AM Gengxuesong (Geng Xuesong) < > gengxuesong@huawei.com> wrote: > >> Hi Sridhar, >> >> >> >> Thanks for your explanation. It is much clearer for me as the following: >> >> =C5=BE UPF < ----- GTP-u tunnel [PDU session]------ > gNB >> >> =C5=BE PDU session contains multiple QoS flows [QFI marker->5QI] >> >> =C5=BE QFI marker in GTP-u extension header >> >> 5QI is not in GTP-u header directly but could be indicated by QFI. So th= e >> QoS requirements presented by 5QI can=E2=80=99t be used/seen by transpor= t network >> in the existing in the current implementation (TEID is similar). And DSC= P >> can act as a mediator between transport network and UPF/gNB. >> >> Maybe the existing question becomes whether DSCP is sufficient for >> passing information from the mobile network to transport network? whethe= r >> there is any simplification or omission of information in the mapping to >> the DSCP? >> >> >> >> Best >> >> Xuesong >> >> >> >> >> >> *From:* Apn [mailto:apn-bounces@ietf.org] *On Behalf Of *Sridhar >> Bhaskaran >> *Sent:* Friday, January 29, 2021 8:06 PM >> *To:* Gengxuesong (Geng Xuesong) >> *Cc:* apn@ietf.org; Uma Chunduri ; Kaippallimalil >> John ; dmm ; Lizhenbin = < >> lizhenbin@huawei.com> >> *Subject:* Re: [Apn] [DMM] Regarding APN Usecase in Mobile Core >> >> >> >> Hi Gengxuesong, >> >> >> >> QFI (mapped to 5QI) and TEID are to identify QoS flows and PDU sessions >> within UPF and gNB. They are not meant for transport network to look int= o. >> UPF and gNB map QFI to DSCP marking in the outer IP header which the >> transport network can use for differentiated services. >> >> >> >> Regards >> >> Sridhar >> >> >> >> On Fri, Jan 29, 2021 at 3:37 PM Gengxuesong (Geng Xuesong) < >> gengxuesong@huawei.com> wrote: >> >> Hi Sridhar, >> >> >> >> Thank you for your additional information. Can I come to a conclusion >> that: both 5QI and TEID have the potential to provide additional >> information for differentiated services in transport network, although t= he >> two parameters act in different scopes? >> >> >> >> Best >> >> Xuesong >> >> >> >> *From:* Sridhar Bhaskaran [mailto:sridhar.bhaskaran@gmail.com] >> *Sent:* Friday, January 22, 2021 12:39 PM >> *To:* Kaippallimalil John >> *Cc:* Gengxuesong (Geng Xuesong) ; Uma Chunduri = < >> umac.ietf@gmail.com>; Lizhenbin ; apn@ietf.org; >> dmm >> *Subject:* Re: [DMM] [Apn] Regarding APN Usecase in Mobile Core >> >> >> >> Hi Xuesong, >> >> >> >> In addition to what John said, in 3GPP networks there is one GTP-u tunne= l >> per bearer (in case of 4G) and one GTP-u tunnel per PDU session (in case= of >> 5G). >> >> >> >> One UE (user equipment - i.e mobile device) may have multiple PDU >> sessions and hence in the network there may be more than one tunnel for = a >> UE. The scope of GTP-u tunnel is from UPF to gNB only. GTP-u does not go >> all the way upto UE. The GTP-u header has a field called "TEID" (tunnel >> endpoint identifier). The TEID in the header identifies a context in UPF >> and gNB. The context gets established through signalling plane. The cont= ext >> provides information on the QoS to be provided for the bearer, PDCP >> ciphering keys applicable for the bearer context etc.,. If there are a >> million UE that are getting connected to a UPF, there could be few milli= on >> GTP-u tunnels (TEID). >> >> >> >> In summary: >> >> 1. The 5QI / QFI marking in the GTP-u extension header provides a lookup >> for the general QoS characteristic applicable for that 5QI >> >> 2. TEID in the GTP-u header provides a lookup for UE and bearer specific >> contextual information for any differentiated treatment. >> >> >> >> Regards >> >> Sridhar >> >> >> >> On Fri, Jan 22, 2021 at 2:55 AM Kaippallimalil John < >> john.kaippallimalil@futurewei.com> wrote: >> >> Hi Xuesong, >> >> >> >> Traffic policy for subscribers is managed per PDU session at the UPF (an= d >> gNB). >> >> GTP-u does provide encapsulation between the end points, but its control >> fields are meant for conveying control semantics between the GTP endpoin= ts: >> they were not intended for IP transport/ traffic underlays. 5QI/QCI etc = are >> in the GTP extension header which may not be ideal to lookup to classify >> each packet in the transport network. >> >> >> >> The entity that classifies data packets (upstream at gNB and downstream >> at UPF-PSA) also inserts the DSCP for that GTP packet. The classificatio= n >> is based on subscriber aspects but may also on be based on its content >> (e.g., using DPI). >> >> >> >> Best Regards, >> >> John >> >> >> >> >> >> *From:* dmm *On Behalf Of *Gengxuesong (Geng >> Xuesong) >> *Sent:* Wednesday, January 20, 2021 8:23 PM >> *To:* Uma Chunduri ; Lizhenbin > > >> *Cc:* apn@ietf.org; dmm >> *Subject:* Re: [DMM] [Apn] Regarding APN Usecase in Mobile Core >> >> >> >> Hi Uma and all, >> >> >> >> I have read the document and got a few questions: >> >> In my understanding, in the UPF where traffic policy is enforced, the >> fine-granularity services are provided. Then what fields in the GTP-u >> encapsulation indicates the traffic's service requirements? When a GTP-u >> tunnel goes into a SRv6 policy, according to which fields in the GTP-u >> encapsulation the DSCP is generated? We know that there are parameters s= uch >> as 5QI/QCI and QFI, whether they are associated with a GTP-u tunnel? >> >> >> >> Best >> >> Xuesong >> >> *From:* Apn [mailto:apn-bounces@ietf.org ] *On >> Behalf Of *Uma Chunduri >> *Sent:* Tuesday, January 19, 2021 3:17 AM >> *To:* Lizhenbin >> *Cc:* apn@ietf.org; dmm >> *Subject:* Re: [Apn] [DMM] Regarding APN Usecase in Mobile Core >> >> >> >> Hi Robin, >> >> >> >> In-line.. >> >> >> >> Cheers! >> -- >> >> Uma C. >> >> >> >> On Mon, Jan 18, 2021 at 5:25 AM Lizhenbin wrote: >> >> Hi APNers and DMMers, >> >> I remember that in the mobile core scenarios the GTP-u tunnel can be set >> up according to the user and application requirements, but I do not >> understand the details. >> >> >> >> [Uma]: Obviously, the best reference for GTP-U is TS 29.281. However, uo= u >> should look into >> https://datatracker.ietf.org/doc/draft-ietf-dmm-5g-uplane-analysis/ >> >> where lot more details and other references related this topic was analy= zed >> (primarily started after/during REL-15, when any other use plane other >> than GTP-U is worthwhile is debated for 5G N9 interface). >> >> >> >> I think when the packet tunneled by GTP-u traverses the APN-based >> transport network, it may be mapped to the corresponding tunnel accordin= g >> to the user and application requirements to implement the uniform servic= e. >> If you are familiar with the principle of GTP-u in the mobile core, plea= se >> help provide some details. >> >> >> >> >> >> Best Regards, >> >> Zhenbin (Robin) >> >> >> >> >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >> >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >> >> >> >> -- >> >> o__ >> _> /__ >> (_) \(_)... Burn fat not fuel - Bike along to a healthier life and >> cleaner >> world! :) >> >> Sridhar Bhaskaran >> >> >> >> -- >> >> o__ >> _> /__ >> (_) \(_)... Burn fat not fuel - Bike along to a healthier life and >> cleaner >> world! :) >> >> Sridhar Bhaskaran >> > > > -- > o__ > _> /__ > (_) \(_)... Burn fat not fuel - Bike along to a healthier life and cleane= r > world! :) > > Sridhar Bhaskaran > > --0000000000003c6d2305ba4fb778 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Sridhar, Xuesong,

<= div>Quick thoughts below [Uma]:

--
Uma C= .

On Sun, Jan 31, 2021 at 8:42 PM Sridhar Bhaskaran <sridhar.bhaskaran@gmail.com> wrote:
Hi Gengxuesong,

On,
<= br>
>> Maybe the existing question becom= es whether DSCP is sufficient for passing information from the mobile network to transport network? whether there is any simplification or omiss= ion of information in the mapping to the DSCP?
[Uma]: First of all, a lot of discussion below was= discussed during 04 version of=C2=A0https://tools.ietf.o= rg/html/draft-clt-dmm-tn-aware-mobility-08. It was presented by John in= one the IETF DMM sessions that time.=C2=A0 And yes, it was limiting and mo= reover a lot of implementations=C2=A0reset DSCP bits in the shared transpor= t scenarios (like WAN=C2=A0 scenario).


3GP= P allows mapping of a GTP-u tunnel (PDU session) to an index to a transport= network configuration / policy via "Network Instance" concept. W= hen the GTP-u tunnel is setup in the UPF by the signalling plane, it provid= es a "Network Instance" which is just a string that acts as an in= dex into UPF's transport layer configuration.
<= div>=C2=A0
[Uma]:=C2=A0 Right and that's natural as overlay i= s processed at the tunnel endpoints (gNB/PSA-UPF/ULCL-UPF/BP-UPF).


Now what the transport layer configuration is - 3GP= P doesn't care as it is out of their remit. If you are using just plain= IP routing, then DSCP (for IPv4) and Flow label (IPv6) are the options to = map a QFI within a GTP-u tunnel to IP transport. However if you are using -= say a source routing technology like SRv6, you may potentially configure t= he UPF to map a slice (PDU session / TEID) and QFI to a specific SID list. = If you use PPR (Preferred path routing), then MTCN-ID is an option.
=C2=A0
[Uma]: I am afraid this may not be p= ossible=C2=A0in all scenarios for example gNB may not be knowing the all un= derlying transport information to encode that way. However, if 5G-AN node i= s integrated with the PE this is a possibility. Another possibility is SRv6= user plane where interoperability scenarios=C2=A0 and overall user plane a= re described in=C2=A0https://tools.ietf.org/html/draft-= ietf-dmm-srv6-mobile-uplane-09=C2=A0

Also note that on= the N3 interface between UPF and gNB, if it is going to traverse a public = network, operators would employ IPSec tunneling for security. So any markin= gs at the transport protocol layer (e.g. UDP source port) will not be visib= le to on path routers due to IPSec. In such a case, the mapping of Slice (P= DU Session / TEID) and QFI should be to the outer IP header in the IPSec tu= nnel. This is where a solution at IP header level helps (e.g DSCP / flow la= bel / SID list)


Regards
Sridhar

=
On Mon, Feb 1, 2021 at 8:10 AM Gengxu= esong (Geng Xuesong) <gengxuesong@huawei.com> wrote:

Hi Sridhar,

=C2=A0

Thanks for your explanation. It is much clearer for me as = the following:

=C5=BE=C2=A0=C2=A0 UPF &= lt; ----- GTP-u tunnel [PDU session]------ > gNB

=C5=BE=C2=A0=C2=A0 PDU s= ession contains multiple QoS flows [QFI marker->5QI]

=C5=BE=C2=A0=C2=A0 QFI m= arker in GTP-u extension header

5QI is not in GTP-u header directly but could be indicated= by QFI. So the QoS requirements presented by 5QI can=E2=80=99t be used/seen by transport network in the existing in the= current implementation (TEID is similar). And DSCP can act as a mediator b= etween transport network and UPF/gNB.

Maybe the existing question becomes whether DSCP is suffic= ient for passing information from the mobile network to transport network? whether there is any simplification or omiss= ion of information in the mapping to the DSCP?

=C2=A0=

Best

Xuesong

=C2=A0=

=C2=A0=

From: Apn [mailto:apn-bounces@ietf.org] On Behalf Of Sridhar Bhaskaran
Sent: Friday, January 29, 2021 8:06 PM
To: Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com>
Cc: apn@ietf.org; Uma Chunduri <umac.ietf@gmail.com>; Kaippallimalil John <john.kaippallimalil@fut= urewei.com>; dmm <dmm@ietf.org>; Lizhenbin <lizhenbin@huawei.com>
Subject: Re: [Apn] [DMM] Regarding APN Usecase in Mobile Core=

=C2=A0

Hi Gengxuesong,

=C2=A0

QFI (mapped to 5QI) and TEID ar= e to identify QoS flows and PDU sessions within UPF and gNB. They are not m= eant for transport network to look into. UPF and gNB map QFI to DSCP markin= g in the outer IP header which the transport network can use for differentiated services.

=C2=A0

Regards

Sridhar

=C2=A0

On Fri, Jan 29, 2021 at 3:37 PM= Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com> wrote:=

Hi Sridhar,

=C2=A0

Thank you for your additional inf= ormation. Can I come to a conclusion that: both 5QI and TEID have the poten= tial to provide additional information for differentiated services in transport network, although the two parameters = act in different scopes?

=C2=A0

Best<= u>

Xuesong

=C2=A0

From: Sridhar Bhaskaran [mailto:sridhar.bhaskaran@gmail.com]
Sent: Friday, January 22, 2021 12:39 PM
To: Kaippallimalil John <john.kaippallimalil@futurewei= .com>
Cc: Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com= >; Uma Chunduri <umac.ietf@gmail.com>; Lizhenbin <lizhenbin@huawei.com>; apn@ietf.o= rg; dmm <dmm@ietf.org>
Subject: Re: [DMM] [Apn] Regarding APN Usecase in Mobile Core=

=C2=A0

Hi Xuesong,<= /u>

=C2=A0

In addition to what John said, = in 3GPP networks there is one GTP-u tunnel per bearer (in case of 4G) and o= ne GTP-u tunnel per PDU session (in case of 5G).

=C2=A0

One UE (user equipment - i.e mo= bile device) may have multiple PDU sessions and hence in the network there = may be more than one tunnel for a UE. The scope of GTP-u tunnel is from UPF to gNB only. GTP-u does not go all the way upto UE. The= GTP-u header has a field called "TEID" (tunnel endpoint identifi= er). The TEID in the header identifies a context in UPF and gNB. The contex= t gets established through signalling plane. The context provides information on the QoS to be provided for the bearer,= =C2=A0 PDCP ciphering keys applicable for the bearer context etc.,. If ther= e are a million UE that are getting connected to a UPF, there could be few = million GTP-u tunnels (TEID).

=C2=A0

In summary:

1. The 5QI / QFI marking in the= GTP-u extension header provides a lookup for the general QoS characteristi= c applicable for that 5QI

2. TEID in the GTP-u header pro= vides a lookup for UE and bearer specific contextual information for any di= fferentiated treatment.

=C2=A0

Regards

Sridhar

=C2=A0

On Fri, Jan 22, 2021 at 2:55 AM= Kaippallimalil John <john.kaippallimalil@futurewei.com> wrote:

Hi Xuesong,<= /u>

=C2=A0

Traffic policy for subscribers is managed per PDU = session at the UPF (and gNB). =C2=A0<= /u>

GTP-u does provide encapsulation between the end p= oints, but its control fields are meant for conveying control semantics between the GTP endpoints: they were not intended for IP= transport/ traffic underlays. 5QI/QCI etc are in the GTP extension header = which may not be ideal to lookup to classify each packet in the transport n= etwork.

=C2=A0

The entity that classifies data packets (upstream = at gNB and downstream at UPF-PSA) also inserts the DSCP for that GTP packet. The classification is based on subscriber aspect= s but may also on be based on its content (e.g., using DPI).

=C2=A0

Best Regards,

John

=C2=A0

=C2=A0

From: dmm <dmm-bounces@ietf.org> On Behalf Of Gengxuesong (Geng Xuesong)
Sent: Wednesday, January 20, 2021 8:23 PM
To: Uma Chunduri <umac.ietf@gmail.com>; Lizhenbin <lizhenbin@huawei.com>
Cc: apn@ietf.org; dmm <dmm@i= etf.org>
Subject: Re: [DMM] [Apn] Regarding APN Usecase in Mobile Core=

=C2=A0

Hi Uma and all,

=C2=A0

I have read the document and got = a few questions:

In my understanding, in the UPF w= here traffic policy is enforced, the fine-granularity services are provided= . Then what fields in the GTP-u encapsulation indicates the traffic's service requirements? When a GTP-u tunnel goes= into a SRv6 policy, according to which fields in the GTP-u encapsulation t= he DSCP is generated? We know that there are parameters such as 5QI/QCI and= QFI, whether they are associated with a GTP-u tunnel?

=C2=A0

Best<= u>

Xuesong

From: Apn [= mailto:apn-bounces@ietf.org] On Behalf Of Uma Chunduri
Sent: Tuesday, January 19, 2021 3:17 AM
To: Lizhenbin <lizhenbin@huawei.com>
Cc: apn@ietf.org; dmm <dmm@i= etf.org>
Subject: Re: [Apn] [DMM] Regarding APN Usecase in Mobile Core=

=C2=A0

Hi Robin,<= /p>

=C2=A0

In-line..<= /p>

=C2=A0

Cheers!
--

Uma C.

=C2=A0

On Mon, Jan 18, 2021 at 5:25 AM= Lizhenbin <li= zhenbin@huawei.com> wrote:

Hi APNers and DMMers,<= /u>

I remember that in the mobi= le core scenarios the GTP-u tunnel can be set up according to the user and application requirements, but I do not understand the deta= ils.

=C2=A0

[Uma]: Obviously, the best refe= rence for GTP-U is TS 29.281. However, uou should look into=C2=A0https://datatracker.ietf.org/doc/draft-ie= tf-dmm-5g-uplane-analysis/ where lot more details and other references=C2=A0related this topic was an= alyzed (primarily started after/during REL-15, when=C2=A0 any other use pla= ne other than GTP-U is worthwhile is debated for 5G N9 interface).

=C2=A0

I think when the packet tun= neled by GTP-u traverses the APN-based transport network, it may be mapped to the corresponding tunnel according to the user and applic= ation requirements to implement the uniform service. If you are familiar wi= th the principle of GTP-u in the mobile core, please help provide some deta= ils.=C2=A0

=C2=A0

=C2=A0

Best Regards,

Zhenbin (Robin)

=C2=A0

=C2=A0

_______________________________= ________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

_______________________________= ________________
dmm mailing list
dmm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/dmm



--

= =C2=A0o__
=C2=A0_> =C2=A0/__
(_) \(_)... Burn fat not fuel - Bike along to a healthier life and cleaner =
world! :)

Sridhar Bhaskaran



--

= =C2=A0o__
=C2=A0_> =C2=A0/__
(_) \(_)... Burn fat not fuel - Bike along to a healthier life and cleaner =
world! :)

Sridhar Bhaskaran



--
=C2=A0o__
=C2=A0_> =C2=A0/__
(_) \(_)... Burn fat not= fuel - Bike along to a healthier life and cleaner
world! :)

S= ridhar Bhaskaran

--0000000000003c6d2305ba4fb778-- From nobody Mon Feb 1 19:00:37 2021 Return-Path: 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 A40353A16C9; Mon, 1 Feb 2021 19:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DIET_1=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 q-o_D4SNvbYV; Mon, 1 Feb 2021 19:00:28 -0800 (PST) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2104.outbound.protection.outlook.com [40.107.243.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCD1D3A16C8; Mon, 1 Feb 2021 19:00:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=L59yBxO27EiKvT0UV6fc35MAUq/Y1/jtTm/zjOeM4iV6XyIbOanKhwOSRGGvDvIHS0gIReucH30hOKS4jrtUR6iWHXXWqyC+LwNdV6JBomds/ci9MI4gEp0/+v1mconS+pQXkl08xGQ+oDuR4Bj1QHSSheXtPKSDHn/2TBUQy33co25Wq486gfJa5TAI3NxaMn7WaY7j5kWkc+sM6fgMHhcNnvGjyzfr0NVcvZ9oWw3+4Enpg7pEcobC732ZjgeEH9aPmiJbS80k45YhIYpcMy++pycHrJ3wgzpBtibZyNiTAoWt1GKOFH4ytiDj2GP+JbACtBYeyg1WFkYUjK9+zw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NN0U3jIeM7mS81IeqkSkRiOy2C0CvRpEZKjrmrs0338=; b=S5u0wVfaEZuQPp6GMFKVoUfqcXvPwcXHuCMgmuaRKZfgwWEgcDq3Fi8fOfuq/eL4Is9GEhsW34PsnOUz6d5PSQd452AIHS92/1E6dfQpLMe9uzGnoKMlaEYywnx99Q2ys74hv2F2MIm6Gwjjdo430zGQXrRa+bAJBuGZWzC1ysV+sD8DxTaJ0STN80qHmOzpH3P4OtHfysiOwRQI6o5jlePft5nNUdbyEIhMMqLzR+1pha9R6QBJQJbRWHqUn0iLnus1+D0DYyJY0XxRKJXa5ZpNsH9CBaqDQn1oAcyIkpjgnGrEaSA0VADG9RSwnxF3ORi2LrLExY4uKNuPzFJ3NA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NN0U3jIeM7mS81IeqkSkRiOy2C0CvRpEZKjrmrs0338=; b=I6XW/PSuk6ai/aYMU/uwL8rZ742NBvZDLDP0z+J9D1/l6Gnd/ocuSRG5xzmgVWv9SgSZI786O1yndGi+cQO0yd+RqJPfr1if/ruCUDZMcL8eVqrqiQIvNRTlV04BSkdDjNhPZR7KHyBC3mfZcK6VNU6x+GfDlrjG5s0a1u3I5Wg= Received: from (2603:10b6:805:55::16) by SA0PR13MB4157.namprd13.prod.outlook.com (2603:10b6:806:9c::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.8; Tue, 2 Feb 2021 03:00:24 +0000 Received: from SN6PR13MB2334.namprd13.prod.outlook.com ([fe80::c0e0:2f3f:efcb:e8c7]) by SN6PR13MB2334.namprd13.prod.outlook.com ([fe80::c0e0:2f3f:efcb:e8c7%7]) with mapi id 15.20.3825.017; Tue, 2 Feb 2021 03:00:24 +0000 From: Linda Dunbar To: "Pengshuping (Peng Shuping)" , Sridhar Bhaskaran , Kaippallimalil John CC: "apn@ietf.org" , "Gengxuesong (Geng Xuesong)" , Uma Chunduri , Lizhenbin , dmm Thread-Topic: [Apn] [DMM] Regarding APN Usecase in Mobile Core Thread-Index: AQHW8Hiof1SWn3OwKUCkXfRz1bdEjao0Gs7AgA0Uf4CAAwtRsA== Date: Tue, 2 Feb 2021 03:00:24 +0000 Message-ID: References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D939966D9@DGGEMM532-MBX.china.huawei.com> <4278D47A901B3041A737953BAA078ADE19864F6F@dggeml512-mbs.china.huawei.com> In-Reply-To: <4278D47A901B3041A737953BAA078ADE19864F6F@dggeml512-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [72.180.73.64] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 07fc387e-cc59-4136-7f5e-08d8c726affb x-ms-traffictypediagnostic: SA0PR13MB4157: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: bSZCz6NCS3X6nHE6/FseotxUntF3ur8y1gGXhZOM7RmzNqu48k64sz+oLVTbtZ5KttgW3QKygaLdi/VK+zGKcsYJxD/LRraleg3YJT+FRA9qhp5566PRCqXJTjbTUvl33pg//x+JWyD4iVlL8v1uEpL6kJJx375gT6vNE3g1GIrYyqV+UK81IUCx7mY5g/lm+zTW07vDrax6fDJoqbbs6/AFVfKjDzn2Bhh2jJg7Xdz8Tif7Ri2q2VMF4OFsqJtJpq6fSLADcO1VxcbzXEper1G3H7GCZR6UThQ7oL9B24KckYurJSAmUWWyhgA0uZr8EwWYx5qgoaAwcnAWDNEer+IgJOf7OEZmaz6cdhK7RDGzEYO3/Mr25QIKG2Rt4FsK4YEIjyhg0L0MyVNGPzV2JiKTLs/BOVXKMmzbm50EHzCcVHqDdGydFumkAYlj05oBL//On3KPMQQXNM+A1c+JH7F2VDsK1UZKMvLNxTS9nZNYP5c1a6lZT6YHEI6jhGycAtRCdNFe209t+0Mgm48YI4049TbaeAydk15QgbFVq9Wlt91FXZfXRtEqa/v8o5WvQsrvpkwzOLj5QUrD++61lX9CGxP9gHNRUG7nqGNK0s8= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR13MB2334.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(396003)(346002)(39850400004)(136003)(366004)(8936002)(71200400001)(66446008)(66556008)(6636002)(83380400001)(2906002)(66574015)(166002)(52536014)(86362001)(55016002)(30864003)(9686003)(8676002)(66476007)(64756008)(5660300002)(316002)(76116006)(4326008)(53546011)(6506007)(966005)(7696005)(478600001)(54906003)(186003)(44832011)(33656002)(110136005)(26005)(66946007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?yKAXXVfTi209RObQUV//g93R5SJPbgzuE4aeF0UaXKmIZ7fz//ylms/kq7dN?= =?us-ascii?Q?N7oerGkjRwlbp6lgkbxqVLBi97+OfXsaL1+URCf592DkRalv6vyZLcqeI/WB?= =?us-ascii?Q?cTR3V8eZ87L7tvN+4nS8mr3f4gLmgy/J7IwBYnvKWLWe3jvTl59x8WHbl3IG?= =?us-ascii?Q?hY6lngBtSMVp5msbs0LCOij4GAMHsKCn0b418nxWATIQMeMg3PjrzmaFuXdF?= =?us-ascii?Q?jMwHE8uLXcy7AbNto7Qd2cg/cztaUFT5/3sWOQHIXmadlkg9mhabyk35XO0r?= =?us-ascii?Q?qprUnboICqd1FkWjJTSSAiVMmSM+f7zT6DNvP1lZLnKzBZM97T/dXmr2+NF5?= =?us-ascii?Q?g+YBjhcVpCOQBAigv6aX8rtXBW3X6i0Iu4e+GN1wwYSzY9ISvLepkyqb4edq?= =?us-ascii?Q?FXJmUr+tcWi25arEDDBD66r0emQjX5u4LKEb05jTk9tSfmpR1heU4qZquEiP?= =?us-ascii?Q?SNXIkaevT6crHss+f08vzDQFTw7A8sXBC1NtU2nQhygxsHfx6Ey9kG+Xayw+?= =?us-ascii?Q?AzHwcKltkA95tYp2w2lFiFrw9Q+VHuDeOR7HO5qSf3zJ8DS3X39rvt3LMZHc?= =?us-ascii?Q?PxqFk9Pp9Y3b5OlHSFmAXEgV+zCRbK9BtvK15bEEAEugnkMIntBzGHvO50Uk?= =?us-ascii?Q?xcuF0ow1n8F6XupbfKHnyuUdOOSEBJjugknkTzcn7BPxRX8Dao1LtdvjW8iq?= =?us-ascii?Q?g4wudNf6jOJg6Z5ACPxvbaKlzi/+ERQRppjfkrLeo5dvMnYf6sCd/J0FW0qd?= =?us-ascii?Q?0JcGLkzsZCNitw6OBfOK5ADmuPWW34JukQxkX+R4M5DbquXJzIf+a3ZBYErg?= =?us-ascii?Q?9ivBjp07UU2n+N3TqnlHGIptjMXU9ZKF/wH5S2ZWVJAbdlIhWSFGoXd2D6rx?= =?us-ascii?Q?wd7Iq8iwcLLOibbriePDecYURyuegbvxF/drguM8l4OaWb7tXkM+C8I0CXip?= =?us-ascii?Q?yiLEG6Sar4jpmL/uX2dcKb6kPM81pgVKe3SI/rl4LoHEqsYrzGRs5/TRZlXc?= =?us-ascii?Q?lxqfg6PPg/DCvK5xlb65AhWk+9lJdz2VNB4gPjHEXRkpeHMJFigybi1KCbv4?= =?us-ascii?Q?VQOkxDMz?= Content-Type: multipart/alternative; boundary="_000_SN6PR13MB2334DDE8E71B22733514410385B59SN6PR13MB2334namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR13MB2334.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 07fc387e-cc59-4136-7f5e-08d8c726affb X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2021 03:00:24.7315 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: +9SGEnKr77mHdpJ+njRTaRHqADQozNWyHar1Vqd3QeVLlk+volH23yU3vxM2l0zQHQxGPbhLqF0WoclEtAJgpg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR13MB4157 Archived-At: Subject: Re: [DMM] [Apn] Regarding APN Usecase in Mobile Core X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2021 03:00:32 -0000 --_000_SN6PR13MB2334DDE8E71B22733514410385B59SN6PR13MB2334namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Shuping, Answers to your questions are inserted below: From: Pengshuping (Peng Shuping) Sent: Saturday, January 30, 2021 10:18 PM To: Linda Dunbar ; Sridhar Bhaskaran ; Kaippallimalil John Cc: apn@ietf.org; Gengxuesong (Geng Xuesong) ; Uma = Chunduri ; Lizhenbin ; dmm Subject: RE: [Apn] [DMM] Regarding APN Usecase in Mobile Core Dear Linda, Many thanks for the reference you pointed to. Through this draft I also rea= d the other draft which seems to be source of this work, https://tools.ietf= .org/html/draft-clt-dmm-tn-aware-mobility-07. I will have to first check whether I= have understood it correctly. MTNC-ID is generated by 3GPP NSSMF (TNF) and unique per path and per traffi= c class but not per flow/session. The MTNC-ID actually can be seen as an in= dicator of a path/slice in the IP transport network. This ID is carried in = the packets and when the packets reach the transport network PE nodes, the = ID will be read out and according to which the path/slice in the IP transpo= rt network can be selected and the traffic will be steered into it. Am I ri= ght? My first question is where is the MTNC-ID first added, on the UE? gNB? Or U= PF? [Linda] MTNC-ID is only valid between gNB and the UPF. The draft suggests m= apping to UDP port number which is managed by the Management Function. So o= n the data packets, if you use Wireshark you can only see the UDP port numb= er. It is the UPF and gNG interpret per the mapping from the Management Fun= ction. It is mentioned in the draft that "to mininise the protocol changes are req= uired and make this underlay tranport independent IPv4/IPv6/MPLS/L2), an op= tion is to provision a mapping of MTNC-ID to a UDP port range of the GTP en= capsulated user packet....This mapping is configured in 3GPP user plane fun= ctions (5G-AN, UPF) and Provider Edge (PE) Routers that process MTNC-IDs." My second question is whether the actual mapping procedure is like this. At= the 5G-AN, the MTNC-ID is mapped to the UDP port range in the GTP-u packet= header due to easier implementation/deployment, and then at the PE router,= the UDP port range in the GTP-u header is used to steer the traffic into t= he selected path/slice. Is it correct? [Linda] Correct. It is good for you to consider to extend to N6 since it is IP to further pr= ovide SLA guarantee and other value added services. Do you plan to continue= to using the UDP port range? [Linda] the UDP port number in the GTP-u tunnel is removed by the UPF funct= ion. So the packets sent to the N6 interface doesn't have the label anymore= . More reasonable approach is having signaling (or messages) between the Ma= nagement function of the 5G Core and N6 network Controller, which is feasib= le if both 5G core and N6 Networks are administrated by the same network op= erator. I just keep wondering whether you have to do this. The use of the UDP port = range is because of the limitation caused by the GTP-u encapsulation. So wh= en it is N6, it is IP based. You may not need to continue this limitation. = On the other hand, the UDP port range itself is also very limited, not very= meaningful. So what I am thinking is that you could use the APN ID in this case. It can= serve your purpose and achieve more service provisioning possibilities. [Linda] That is possible. Question: is APN-ID an additional Metadata insert= ed into data packets on top of SRv6 header? Currently, the draft describes using the labels supported by the N6 IP netw= ork, i.e. if N6 IP network is SR, uses the SR label, if the N6 IP network i= s MPLS, use the MPLS label, etc. Thank you very much for starting the discussions in the 5G scenario and N6 = interface in particular! I believe it is a very important case for APN, and= it can be integrated with MEC etc. Best regards, Shuping From: Apn [mailto:apn-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Saturday, January 23, 2021 4:58 AM To: Sridhar Bhaskaran >; Kaippallimalil John > Cc: apn@ietf.org; Gengxuesong (Geng Xuesong) >; Uma Chunduri >; Lizhenbin >; dmm > Subject: Re: [Apn] [DMM] Regarding APN Usecase in Mobile Core Many thanks to Sridhar and John 's insightful description of GTP-u tunnel f= or both 4G and 5G. IMHO, APN should focus on the 5G case, i.e. potentially hundreds of thousan= ds (or even millions) of GTP-u tunnels between a pair of one gNB and one UP= F. I think two scenarios worth exploring further separately: 1. 5G core can exchange signal with the IP network (the N6 interface), m= ore likely the 5G Core and N6 network are administrated by the same network= operator. * 5G core can tag the packets before handing off to the N6 interface= (i.e. the IP network), such as inserting a metadata to the data packets * inform the IP network of the meaning of the inserted Metadata. * The IP network needs to remove the metadata before handing the pac= kets to their destinations 1. There is no communication between the 5G core and the IP network, the= n the IP network can only depend on the priority bits added by the UE, whic= h can be very unpredictable. The Section 4 (Mobility Packet Transition in the Data Network) and the Sect= ion 5 (Transport Network characteristics Mapping to SR-TE Paths) have good = description on how to extend 5G core's TN aware mobility information for va= rious TE paths within IP networks. https://datatracker.ietf.org/doc/draft-m= cd-rtgwg-extension-tn-aware-mobility/ Linda Dunbar From: Apn > On Behalf Of = Sridhar Bhaskaran Sent: Thursday, January 21, 2021 10:39 PM To: Kaippallimalil John > Cc: apn@ietf.org; Gengxuesong (Geng Xuesong) >; Uma Chunduri >; Lizhenbin >; dmm > Subject: Re: [Apn] [DMM] Regarding APN Usecase in Mobile Core Hi Xuesong, In addition to what John said, in 3GPP networks there is one GTP-u tunnel p= er bearer (in case of 4G) and one GTP-u tunnel per PDU session (in case of = 5G). One UE (user equipment - i.e mobile device) may have multiple PDU sessions = and hence in the network there may be more than one tunnel for a UE. The sc= ope of GTP-u tunnel is from UPF to gNB only. GTP-u does not go all the way = upto UE. The GTP-u header has a field called "TEID" (tunnel endpoint identi= fier). The TEID in the header identifies a context in UPF and gNB. The cont= ext gets established through signalling plane. The context provides informa= tion on the QoS to be provided for the bearer, PDCP ciphering keys applica= ble for the bearer context etc.,. If there are a million UE that are gettin= g connected to a UPF, there could be few million GTP-u tunnels (TEID). In summary: 1. The 5QI / QFI marking in the GTP-u extension header provides a lookup fo= r the general QoS characteristic applicable for that 5QI 2. TEID in the GTP-u header provides a lookup for UE and bearer specific co= ntextual information for any differentiated treatment. Regards Sridhar On Fri, Jan 22, 2021 at 2:55 AM Kaippallimalil John > wrote: Hi Xuesong, Traffic policy for subscribers is managed per PDU session at the UPF (and g= NB). GTP-u does provide encapsulation between the end points, but its control fi= elds are meant for conveying control semantics between the GTP endpoints: t= hey were not intended for IP transport/ traffic underlays. 5QI/QCI etc are = in the GTP extension header which may not be ideal to lookup to classify ea= ch packet in the transport network. The entity that classifies data packets (upstream at gNB and downstream at = UPF-PSA) also inserts the DSCP for that GTP packet. The classification is b= ased on subscriber aspects but may also on be based on its content (e.g., u= sing DPI). Best Regards, John From: dmm > On Behalf Of = Gengxuesong (Geng Xuesong) Sent: Wednesday, January 20, 2021 8:23 PM To: Uma Chunduri >; Lizhenb= in > Cc: apn@ietf.org; dmm > Subject: Re: [DMM] [Apn] Regarding APN Usecase in Mobile Core Hi Uma and all, I have read the document and got a few questions: In my understanding, in the UPF where traffic policy is enforced, the fine-= granularity services are provided. Then what fields in the GTP-u encapsulat= ion indicates the traffic's service requirements? When a GTP-u tunnel goes = into a SRv6 policy, according to which fields in the GTP-u encapsulation th= e DSCP is generated? We know that there are parameters such as 5QI/QCI and = QFI, whether they are associated with a GTP-u tunnel? Best Xuesong From: Apn [mailto:apn-bounces@ietf.org] On Behalf Of Uma Chunduri Sent: Tuesday, January 19, 2021 3:17 AM To: Lizhenbin > Cc: apn@ietf.org; dmm > Subject: Re: [Apn] [DMM] Regarding APN Usecase in Mobile Core Hi Robin, In-line.. Cheers! -- Uma C. On Mon, Jan 18, 2021 at 5:25 AM Lizhenbin > wrote: Hi APNers and DMMers, I remember that in the mobile core scenarios the GTP-u tunnel can be set up= according to the user and application requirements, but I do not understan= d the details. [Uma]: Obviously, the best reference for GTP-U is TS 29.281. However, uou s= hould look into https://datatracker.ietf.org/doc/draft-ietf-dmm-5g-uplane-a= nalysis/ where lot more details and other references related this topic was a= nalyzed (primarily started after/during REL-15, when any other use plane o= ther than GTP-U is worthwhile is debated for 5G N9 interface). I think when the packet tunneled by GTP-u traverses the APN-based transport= network, it may be mapped to the corresponding tunnel according to the use= r and application requirements to implement the uniform service. If you are= familiar with the principle of GTP-u in the mobile core, please help provi= de some details. Best Regards, Zhenbin (Robin) _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm -- o__ _> /__ (_) \(_)... Burn fat not fuel - Bike along to a healthier life and cleaner world! :) Sridhar Bhaskaran --_000_SN6PR13MB2334DDE8E71B22733514410385B59SN6PR13MB2334namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Shuping,

 

Answers to your questions are inserted below:

 

 

From: Pengshuping (Peng Shuping) <pengshup= ing@huawei.com>
Sent: Saturday, January 30, 2021 10:18 PM
To: Linda Dunbar <linda.dunbar@futurewei.com>; Sridhar Bhaskar= an <sridhar.bhaskaran@gmail.com>; Kaippallimalil John <john.kaippa= llimalil@futurewei.com>
Cc: apn@ietf.org; Gengxuesong (Geng Xuesong) <gengxuesong@huawei.= com>; Uma Chunduri <umac.ietf@gmail.com>; Lizhenbin <lizhenbin@= huawei.com>; dmm <dmm@ietf.org>
Subject: RE: [Apn] [DMM] Regarding APN Usecase in Mobile Core

 

Dear = Linda,

=  

Many = thanks for the reference you pointed to. Through this draft I also read the= other draft which seems to be source of this work, https://tools.ietf.org/html/draft-clt-dmm-tn-aware-mobility-07. I will = have to first check whether I have understood it correctly.

=  

MTNC-= ID is generated by 3GPP NSSMF (TNF) and unique per path and per traffic cla= ss but not per flow/session. The MTNC-ID actually can be seen as an indicat= or of a path/slice in the IP transport network. This ID is carried in the packets and when the packets reach the = transport network PE nodes, the ID will be read out and according to which = the path/slice in the IP transport network can be selected and the traffic = will be steered into it. Am I right?

=  

My fi= rst question is where is the MTNC-ID first added, on the UE? gNB? Or UPF?

[Linda] MTNC-ID is only valid between gNB and the UP= F. The draft suggests mapping to UDP port number which is managed by the Ma= nagement Function. So on the data packets, if you use Wireshark you can onl= y see the UDP port number. It is the UPF and gNG interpret per the mapping from the Management Function. <= /o:p>

=  

It is= mentioned in the draft that “to mininise the protocol changes are re= quired and make this underlay tranport independent IPv4/IPv6/MPLS/L2), an o= ption is to provision a mapping of MTNC-ID to a UDP port range of the GTP encapsulated user packet….This mappin= g is configured in 3GPP user plane functions (5G-AN, UPF) and Provider Edge= (PE) Routers that process MTNC-IDs.”

=  

My se= cond question is whether the actual mapping procedure is like this. At the = 5G-AN, the MTNC-ID is mapped to the UDP port range in the GTP-u packet head= er due to easier implementation/deployment, and then at the PE router, the UDP port range in the GTP-u header is used = to steer the traffic into the selected path/slice. Is it correct?

 

[Linda] Correct.

 

=  

It is= good for you to consider to extend to N6 since it is IP to further provide= SLA guarantee and other value added services. Do you plan to continue to u= sing the UDP port range?

 

[Linda] the UDP port number in the GTP-u tunnel is r= emoved by the UPF function. So the packets sent to the N6 interface doesn&#= 8217;t have the label anymore. More reasonable approach is having signaling= (or messages) between the Management function of the 5G Core and N6 network Controller, which is feasible if both 5G cor= e and N6 Networks are administrated by the same network operator.

 

I jus= t keep wondering whether you have to do this. The use of the UDP port range= is because of the limitation caused by the GTP-u encapsulation. So when it= is N6, it is IP based. You may not need to continue this limitation. On the other hand, the UDP port range it= self is also very limited, not very meaningful.

=  

So wh= at I am thinking is that you could use the APN ID in this case. It can serv= e your purpose and achieve more service provisioning possibilities.

[Linda] That is possible. Question: is APN-ID an add= itional Metadata inserted into data packets on top of SRv6 header?

Currently, the draft describes using the labels supp= orted by the N6 IP network, i.e. if N6 IP network is SR, uses the SR label,= if the N6 IP network is MPLS, use the MPLS label, etc.  

=  

Thank= you very much for starting the discussions in the 5G scenario and N6 inter= face in particular! I believe it is a very important case for APN, and it c= an be integrated with MEC etc.

=  

Best = regards,

Shupi= ng

=  

=  

From: Apn [mailto:apn-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Saturday, January 23, 2021 4:58 AM
To: Sridhar Bhaskaran <sridhar.bhaskaran@gmail.com>; Kaippallimalil John <john.kaippallimalil@futurewei= .com>
Cc: apn@ietf.org; Gengxuesong (G= eng Xuesong) <gengxuesong@huaw= ei.com>; Uma Chunduri <uma= c.ietf@gmail.com>; Lizhenbin <lizhenbin@huawei.com>; dmm <dmm@ietf.org>
Subject: Re: [Apn] [DMM] Regarding APN Usecase in Mobile Core

 

Many thanks to Sridhar and John ‘s insightful = description of GTP-u tunnel for both 4G and 5G.

IMHO, APN should focus on the 5G case, i.e. potentia= lly hundreds of thousands (or even millions) of GTP-u tunnels between a pai= r of one gNB and one UPF.

I think two scenarios worth exploring further separa= tely:

  1. 5G core can excha= nge signal with the IP network (the N6 interface), more likely the 5G Core = and N6 network are administrated by the same network operator.
    1. 5G core can tag t= he packets before handing off to the N6 interface (i.e. the IP network), su= ch as inserting a metadata to the data packets
    2. i= nform the IP network of the meaning of the inserted Metadata.
    3. T= he IP network needs to remove the metadata before handing the packets to th= eir destinations

 =

  1. There is no commu= nication between the 5G core and the IP network, then the IP network can on= ly depend on the priority bits added by the UE, which can be very unpredict= able.

 

The Section 4 (Mobility Packet Transition in the Dat= a Network) and the Section 5 (Transport Network characteristics Mapping to = SR-TE Paths) have good description on how to extend 5G core’s TN awar= e mobility information for various TE paths within IP networks. https://datatracker.ietf.org/doc/draft-mcd-rtgwg-extension-tn-aware-mobilit= y/

 

 

Linda Dunbar

From: Apn <apn-bounces@ietf.org> On Behalf Of Sridhar Bhaskaran
Sent: Thursday, January 21, 2021 10:39 PM
To: Kaippallimalil John <john.kaippallimalil@futurewei.com>
Cc: apn@ietf.org; Gengxuesong (G= eng Xuesong) <gengxuesong@huaw= ei.com>; Uma Chunduri <uma= c.ietf@gmail.com>; Lizhenbin <lizhenbin@huawei.com>; dmm <dmm@ietf.org>
Subject: Re: [Apn] [DMM] Regarding APN Usecase in Mobile Core

 

Hi Xuesong,

 

In addition to what John said, in 3GPP networks ther= e is one GTP-u tunnel per bearer (in case of 4G) and one GTP-u tunnel per P= DU session (in case of 5G).

 

One UE (user equipment - i.e mobile device) may have= multiple PDU sessions and hence in the network there may be more than one = tunnel for a UE. The scope of GTP-u tunnel is from UPF to gNB only. GTP-u d= oes not go all the way upto UE. The GTP-u header has a field called "TEID" (tunnel endpoint identifi= er). The TEID in the header identifies a context in UPF and gNB. The contex= t gets established through signalling plane. The context provides informati= on on the QoS to be provided for the bearer,  PDCP ciphering keys applicable for the bearer context etc.,. If there are = a million UE that are getting connected to a UPF, there could be few millio= n GTP-u tunnels (TEID).

 

In summary:

1. The 5QI / QFI marking in the GTP-u extension head= er provides a lookup for the general QoS characteristic applicable for that= 5QI

2. TEID in the GTP-u header provides a lookup for UE= and bearer specific contextual information for any differentiated treatmen= t.

 

Regards

Sridhar

 

On Fri, Jan 22, 2021 at 2:55 AM Kaippallimalil John = <john.kaippallimali= l@futurewei.com> wrote:

Hi Xuesong,

 

Traffic policy for subscribers is managed per PDU session at the U= PF (and gNB).  

GTP-u does provide encapsulation between the end points, but its c= ontrol fields are meant for conveying control semantics between the GTP end= points: they were not intended for IP transport/ traffic underlays. 5QI/QCI etc are in the GTP extension header = which may not be ideal to lookup to classify each packet in the transport n= etwork.

 

The entity that classifies data packets (upstream at gNB and downs= tream at UPF-PSA) also inserts the DSCP for that GTP packet. The classifica= tion is based on subscriber aspects but may also on be based on its content (e.g., using DPI).

 

Best Regards,

John

 

 

From: dmm <dmm-bounces@ietf.org> On Behalf Of Gengxuesong (Geng Xuesong)
Sent: Wednesday, January 20, 2021 8:23 PM
To: Uma Chunduri <umac.ietf@gmail.com>; Lizhenbin <lizhenbin@huawei.com>
Cc: apn@ietf.org; dmm <dmm@ietf.org<= /a>>
Subject: Re: [DMM] [Apn] Regarding APN Usecase in Mobile Core

 

Hi Uma and = all,

 

I have read= the document and got a few questions:

In my under= standing, in the UPF where traffic policy is enforced, the fine-granularity= services are provided. Then what fields in the GTP-u encapsulation indicat= es the traffic's service requirements? When a GTP-u tunnel goes into a SRv6 policy, according to which fields in = the GTP-u encapsulation the DSCP is generated? We know that there are param= eters such as 5QI/QCI and QFI, whether they are associated with a GTP-u tun= nel?

 

Best=

Xuesong

From: Apn [mailto:apn-bounces@ietf.org] On Behalf Of Uma Chunduri
Sent: Tuesday, January 19, 2021 3:17 AM
To: Lizhenbin <lizhenbin@huawei.com>
Cc: apn@ietf.org; dmm <dmm@ietf.org<= /a>>
Subject: Re: [Apn] [DMM] Regarding APN Usecase in Mobile Core

 

Hi Robin,

 

In-line..

 

Cheers!
--

Uma C.

 

Hi APNers and DMMers,

I remember that in = the mobile core scenarios the GTP-u tunnel can be set up according to the u= ser and application requirements, but I do not understand the details.

 

[Uma]: Obviously, the best reference for GTP-U is TS 29.281. Howev= er, uou should look into https:= //datatracker.ietf.org/doc/draft-ietf-dmm-5g-uplane-analysis/ where lot more details and other references related this topic was an= alyzed (primarily started after/during REL-15, when  any other use pla= ne other than GTP-U is worthwhile is debated for 5G N9 interface).

 

I think when the pa= cket tunneled by GTP-u traverses the APN-based transport network, it may be= mapped to the corresponding tunnel according to the user and application requirements to implement the uniform service.= If you are familiar with the principle of GTP-u in the mobile core, please= help provide some details. 

 <= /o:p>

 <= /o:p>

Best Regards,

Zhenbin (Robin)

 <= /o:p>

 <= /o:p>

_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm



--

 o__
 _>  /__
(_) \(_)... Burn fat not fuel - Bike along to a healthier life and cleaner =
world! :)

Sridhar Bhaskaran

--_000_SN6PR13MB2334DDE8E71B22733514410385B59SN6PR13MB2334namp_-- From nobody Tue Feb 2 01:16:00 2021 Return-Path: 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 37FA93A0B70; Tue, 2 Feb 2021 01:15:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DIET_1=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 r_ID_uEH4C8w; Tue, 2 Feb 2021 01:15:52 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1A003A091B; Tue, 2 Feb 2021 01:15:51 -0800 (PST) Received: from fraeml740-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4DVJvh0Ylwz67jMn; Tue, 2 Feb 2021 17:11:12 +0800 (CST) Received: from fraeml740-chm.china.huawei.com (10.206.15.221) by fraeml740-chm.china.huawei.com (10.206.15.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Tue, 2 Feb 2021 10:15:49 +0100 Received: from DGGEML421-HUB.china.huawei.com (10.1.199.38) by fraeml740-chm.china.huawei.com (10.206.15.221) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.2106.2 via Frontend Transport; Tue, 2 Feb 2021 10:15:48 +0100 Received: from DGGEML512-MBS.china.huawei.com ([169.254.3.112]) by dggeml421-hub.china.huawei.com ([10.1.199.38]) with mapi id 14.03.0509.000; Tue, 2 Feb 2021 17:15:41 +0800 From: "Pengshuping (Peng Shuping)" To: Linda Dunbar , Sridhar Bhaskaran , Kaippallimalil John CC: "apn@ietf.org" , "Gengxuesong (Geng Xuesong)" , Uma Chunduri , Lizhenbin , dmm Thread-Topic: [Apn] [DMM] Regarding APN Usecase in Mobile Core Thread-Index: AQHW8HiyOJ8wnjtHwEm6Bajj1koq5qozm3CAgA2F69CAApaxAIAA7jGw Date: Tue, 2 Feb 2021 09:15:41 +0000 Message-ID: <4278D47A901B3041A737953BAA078ADE19878637@dggeml512-mbs.china.huawei.com> References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D939966D9@DGGEMM532-MBX.china.huawei.com> <4278D47A901B3041A737953BAA078ADE19864F6F@dggeml512-mbs.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.153.194.197] Content-Type: multipart/alternative; boundary="_000_4278D47A901B3041A737953BAA078ADE19878637dggeml512mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DMM] [Apn] Regarding APN Usecase in Mobile Core X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2021 09:15:55 -0000 --_000_4278D47A901B3041A737953BAA078ADE19878637dggeml512mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Linda, Thank you for your clarification! The APN ID is independent of the data plane, which could be MPLS, VXLAN, SR= /SRv6 and other tunnel technologies that are adopted to provide services wi= thin a service provider's limited domain. Best regards, Shuping From: Apn [mailto:apn-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Tuesday, February 2, 2021 11:00 AM To: Pengshuping (Peng Shuping) ; Sridhar Bhaskaran = ; Kaippallimalil John Cc: apn@ietf.org; Gengxuesong (Geng Xuesong) ; Uma = Chunduri ; Lizhenbin ; dmm Subject: Re: [Apn] [DMM] Regarding APN Usecase in Mobile Core Shuping, Answers to your questions are inserted below: From: Pengshuping (Peng Shuping) > Sent: Saturday, January 30, 2021 10:18 PM To: Linda Dunbar >; Sridhar Bhaskaran >; Kaippallimalil John > Cc: apn@ietf.org; Gengxuesong (Geng Xuesong) >; Uma Chunduri >; Lizhenbin >; dmm > Subject: RE: [Apn] [DMM] Regarding APN Usecase in Mobile Core Dear Linda, Many thanks for the reference you pointed to. Through this draft I also rea= d the other draft which seems to be source of this work, https://tools.ietf= .org/html/draft-clt-dmm-tn-aware-mobility-07. I will have to first check whether I= have understood it correctly. MTNC-ID is generated by 3GPP NSSMF (TNF) and unique per path and per traffi= c class but not per flow/session. The MTNC-ID actually can be seen as an in= dicator of a path/slice in the IP transport network. This ID is carried in = the packets and when the packets reach the transport network PE nodes, the = ID will be read out and according to which the path/slice in the IP transpo= rt network can be selected and the traffic will be steered into it. Am I ri= ght? My first question is where is the MTNC-ID first added, on the UE? gNB? Or U= PF? [Linda] MTNC-ID is only valid between gNB and the UPF. The draft suggests m= apping to UDP port number which is managed by the Management Function. So o= n the data packets, if you use Wireshark you can only see the UDP port numb= er. It is the UPF and gNG interpret per the mapping from the Management Fun= ction. It is mentioned in the draft that "to mininise the protocol changes are req= uired and make this underlay tranport independent IPv4/IPv6/MPLS/L2), an op= tion is to provision a mapping of MTNC-ID to a UDP port range of the GTP en= capsulated user packet....This mapping is configured in 3GPP user plane fun= ctions (5G-AN, UPF) and Provider Edge (PE) Routers that process MTNC-IDs." My second question is whether the actual mapping procedure is like this. At= the 5G-AN, the MTNC-ID is mapped to the UDP port range in the GTP-u packet= header due to easier implementation/deployment, and then at the PE router,= the UDP port range in the GTP-u header is used to steer the traffic into t= he selected path/slice. Is it correct? [Linda] Correct. It is good for you to consider to extend to N6 since it is IP to further pr= ovide SLA guarantee and other value added services. Do you plan to continue= to using the UDP port range? [Linda] the UDP port number in the GTP-u tunnel is removed by the UPF funct= ion. So the packets sent to the N6 interface doesn't have the label anymore= . More reasonable approach is having signaling (or messages) between the Ma= nagement function of the 5G Core and N6 network Controller, which is feasib= le if both 5G core and N6 Networks are administrated by the same network op= erator. I just keep wondering whether you have to do this. The use of the UDP port = range is because of the limitation caused by the GTP-u encapsulation. So wh= en it is N6, it is IP based. You may not need to continue this limitation. = On the other hand, the UDP port range itself is also very limited, not very= meaningful. So what I am thinking is that you could use the APN ID in this case. It can= serve your purpose and achieve more service provisioning possibilities. [Linda] That is possible. Question: is APN-ID an additional Metadata insert= ed into data packets on top of SRv6 header? Currently, the draft describes using the labels supported by the N6 IP netw= ork, i.e. if N6 IP network is SR, uses the SR label, if the N6 IP network i= s MPLS, use the MPLS label, etc. Thank you very much for starting the discussions in the 5G scenario and N6 = interface in particular! I believe it is a very important case for APN, and= it can be integrated with MEC etc. Best regards, Shuping From: Apn [mailto:apn-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Saturday, January 23, 2021 4:58 AM To: Sridhar Bhaskaran >; Kaippallimalil John > Cc: apn@ietf.org; Gengxuesong (Geng Xuesong) >; Uma Chunduri >; Lizhenbin >; dmm > Subject: Re: [Apn] [DMM] Regarding APN Usecase in Mobile Core Many thanks to Sridhar and John 's insightful description of GTP-u tunnel f= or both 4G and 5G. IMHO, APN should focus on the 5G case, i.e. potentially hundreds of thousan= ds (or even millions) of GTP-u tunnels between a pair of one gNB and one UP= F. I think two scenarios worth exploring further separately: 1) 5G core can exchange signal with the IP network (the N6 interface),= more likely the 5G Core and N6 network are administrated by the same netwo= rk operator. a. 5G core can tag the packets before handing off to the N6 interface = (i.e. the IP network), such as inserting a metadata to the data packets b. inform the IP network of the meaning of the inserted Metadata. c. The IP network needs to remove the metadata before handing the pack= ets to their destinations 2) There is no communication between the 5G core and the IP network, t= hen the IP network can only depend on the priority bits added by the UE, wh= ich can be very unpredictable. The Section 4 (Mobility Packet Transition in the Data Network) and the Sect= ion 5 (Transport Network characteristics Mapping to SR-TE Paths) have good = description on how to extend 5G core's TN aware mobility information for va= rious TE paths within IP networks. https://datatracker.ietf.org/doc/draft-m= cd-rtgwg-extension-tn-aware-mobility/ Linda Dunbar From: Apn > On Behalf Of = Sridhar Bhaskaran Sent: Thursday, January 21, 2021 10:39 PM To: Kaippallimalil John > Cc: apn@ietf.org; Gengxuesong (Geng Xuesong) >; Uma Chunduri >; Lizhenbin >; dmm > Subject: Re: [Apn] [DMM] Regarding APN Usecase in Mobile Core Hi Xuesong, In addition to what John said, in 3GPP networks there is one GTP-u tunnel p= er bearer (in case of 4G) and one GTP-u tunnel per PDU session (in case of = 5G). One UE (user equipment - i.e mobile device) may have multiple PDU sessions = and hence in the network there may be more than one tunnel for a UE. The sc= ope of GTP-u tunnel is from UPF to gNB only. GTP-u does not go all the way = upto UE. The GTP-u header has a field called "TEID" (tunnel endpoint identi= fier). The TEID in the header identifies a context in UPF and gNB. The cont= ext gets established through signalling plane. The context provides informa= tion on the QoS to be provided for the bearer, PDCP ciphering keys applica= ble for the bearer context etc.,. If there are a million UE that are gettin= g connected to a UPF, there could be few million GTP-u tunnels (TEID). In summary: 1. The 5QI / QFI marking in the GTP-u extension header provides a lookup fo= r the general QoS characteristic applicable for that 5QI 2. TEID in the GTP-u header provides a lookup for UE and bearer specific co= ntextual information for any differentiated treatment. Regards Sridhar On Fri, Jan 22, 2021 at 2:55 AM Kaippallimalil John > wrote: Hi Xuesong, Traffic policy for subscribers is managed per PDU session at the UPF (and g= NB). GTP-u does provide encapsulation between the end points, but its control fi= elds are meant for conveying control semantics between the GTP endpoints: t= hey were not intended for IP transport/ traffic underlays. 5QI/QCI etc are = in the GTP extension header which may not be ideal to lookup to classify ea= ch packet in the transport network. The entity that classifies data packets (upstream at gNB and downstream at = UPF-PSA) also inserts the DSCP for that GTP packet. The classification is b= ased on subscriber aspects but may also on be based on its content (e.g., u= sing DPI). Best Regards, John From: dmm > On Behalf Of = Gengxuesong (Geng Xuesong) Sent: Wednesday, January 20, 2021 8:23 PM To: Uma Chunduri >; Lizhenb= in > Cc: apn@ietf.org; dmm > Subject: Re: [DMM] [Apn] Regarding APN Usecase in Mobile Core Hi Uma and all, I have read the document and got a few questions: In my understanding, in the UPF where traffic policy is enforced, the fine-= granularity services are provided. Then what fields in the GTP-u encapsulat= ion indicates the traffic's service requirements? When a GTP-u tunnel goes = into a SRv6 policy, according to which fields in the GTP-u encapsulation th= e DSCP is generated? We know that there are parameters such as 5QI/QCI and = QFI, whether they are associated with a GTP-u tunnel? Best Xuesong From: Apn [mailto:apn-bounces@ietf.org] On Behalf Of Uma Chunduri Sent: Tuesday, January 19, 2021 3:17 AM To: Lizhenbin > Cc: apn@ietf.org; dmm > Subject: Re: [Apn] [DMM] Regarding APN Usecase in Mobile Core Hi Robin, In-line.. Cheers! -- Uma C. On Mon, Jan 18, 2021 at 5:25 AM Lizhenbin > wrote: Hi APNers and DMMers, I remember that in the mobile core scenarios the GTP-u tunnel can be set up= according to the user and application requirements, but I do not understan= d the details. [Uma]: Obviously, the best reference for GTP-U is TS 29.281. However, uou s= hould look into https://datatracker.ietf.org/doc/draft-ietf-dmm-5g-uplane-a= nalysis/ where lot more details and other references related this topic was a= nalyzed (primarily started after/during REL-15, when any other use plane o= ther than GTP-U is worthwhile is debated for 5G N9 interface). I think when the packet tunneled by GTP-u traverses the APN-based transport= network, it may be mapped to the corresponding tunnel according to the use= r and application requirements to implement the uniform service. If you are= familiar with the principle of GTP-u in the mobile core, please help provi= de some details. Best Regards, Zhenbin (Robin) _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm -- o__ _> /__ (_) \(_)... Burn fat not fuel - Bike along to a healthier life and cleaner world! :) Sridhar Bhaskaran --_000_4278D47A901B3041A737953BAA078ADE19878637dggeml512mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Linda,

 

Thank you for your clarification!

 

The APN ID is independent of the data plane, which could be MPLS,= VXLAN, SR/SRv6 and other tunnel technologies that are adopted to provide s= ervices within a service provider’s limited domain.

 

Best regards,

Shuping

 

 

 

From: Apn [mailto:apn-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Tuesday, February 2, 2021 11:00 AM
To: Pengshuping (Peng Shuping) <pengshuping@huawei.com>; Sridh= ar Bhaskaran <sridhar.bhaskaran@gmail.com>; Kaippallimalil John <j= ohn.kaippallimalil@futurewei.com>
Cc: apn@ietf.org; Gengxuesong (Geng Xuesong) <gengxuesong@huawei.= com>; Uma Chunduri <umac.ietf@gmail.com>; Lizhenbin <lizhenbin@= huawei.com>; dmm <dmm@ietf.org>
Subject: Re: [Apn] [DMM] Regarding APN Usecase in Mobile Core

 

Shuping,

 

Answers to your questions are i= nserted below:

 

 

From: Pengshuping (Peng Shuping) <pengshuping@huawei.com>
Sent: Saturday, January 30, 2021 10:18 PM
To: Linda Dunbar <l= inda.dunbar@futurewei.com>; Sridhar Bhaskaran <sridhar.bhaskaran@gmail.com>; Kaippalli= malil John <john.ka= ippallimalil@futurewei.com>
Cc: apn@ietf.org; Gengxuesong (G= eng Xuesong) <gengxuesong@huaw= ei.com>; Uma Chunduri <uma= c.ietf@gmail.com>; Lizhenbin <lizhenbin@huawei.com>; dmm <dmm@ietf.org>
Subject: RE: [Apn] [DMM] Regarding APN Usecase in Mobile Core

 

Dear Linda,

 

Many thanks for the reference you pointed to. Through this draft = I also read the other draft which seems to be source of this work, https://tools.ietf.org/html/draft-clt-dmm-tn-aware-mobility-07. I will = have to first check whether I have understood it correctly.

 

MTNC-ID is generated by 3GPP NSSMF (TNF) and unique per path and = per traffic class but not per flow/session. The MTNC-ID actually can be see= n as an indicator of a path/slice in the IP transport network. This ID is carried in the packets and when the packe= ts reach the transport network PE nodes, the ID will be read out and accord= ing to which the path/slice in the IP transport network can be selected and= the traffic will be steered into it. Am I right?

 

My first question is where is the MTNC-ID first added, on the UE?= gNB? Or UPF?

[Linda] MTNC-ID is only valid b= etween gNB and the UPF. The draft suggests mapping to UDP port number which= is managed by the Management Function. So on the data packets, if you use = Wireshark you can only see the UDP port number. It is the UPF and gNG interpret per the mapping from the Managemen= t Function.

 

It is mentioned in the draft that “to mininise the protocol= changes are required and make this underlay tranport independent IPv4/IPv6= /MPLS/L2), an option is to provision a mapping of MTNC-ID to a UDP port range of the GTP encapsulated user packet….= This mapping is configured in 3GPP user plane functions (5G-AN, UPF) and Pr= ovider Edge (PE) Routers that process MTNC-IDs.”

 

My second question is whether the actual mapping procedure is lik= e this. At the 5G-AN, the MTNC-ID is mapped to the UDP port range in the GT= P-u packet header due to easier implementation/deployment, and then at the PE router, the UDP port range in the GTP-u header is used = to steer the traffic into the selected path/slice. Is it correct?

 

[Linda] Correct.

 

 

It is good for you to consider to extend to N6 since it is IP to = further provide SLA guarantee and other value added services. Do you plan t= o continue to using the UDP port range?

 

[Linda] the UDP port number in = the GTP-u tunnel is removed by the UPF function. So the packets sent to the= N6 interface doesn’t have the label anymore. More reasonable approac= h is having signaling (or messages) between the Management function of the 5G Core and N6 network Controller, which is= feasible if both 5G core and N6 Networks are administrated by the same net= work operator.

 

I just keep wondering whether you have to do this. The use of the= UDP port range is because of the limitation caused by the GTP-u encapsulat= ion. So when it is N6, it is IP based. You may not need to continue this limitation. On the other hand, the UDP p= ort range itself is also very limited, not very meaningful.

 

So what I am thinking is that you could use the APN ID in this ca= se. It can serve your purpose and achieve more service provisioning possibi= lities.

[Linda] That is possible. Quest= ion: is APN-ID an additional Metadata inserted into data packets on top of = SRv6 header?

Currently, the draft describes = using the labels supported by the N6 IP network, i.e. if N6 IP network is S= R, uses the SR label, if the N6 IP network is MPLS, use the MPLS label, etc= .  

 

Thank you very much for starting the discussions in the 5G scenar= io and N6 interface in particular! I believe it is a very important case fo= r APN, and it can be integrated with MEC etc.

 

Best regards,

Shuping

 

 

From: Apn [mailto:apn-bounces= @ietf.org] On Behalf Of Linda Dunbar
Sent: Saturday, January 23, 2021 4:58 AM
To: Sridhar Bhaskaran <sridhar.bhaskaran@gmail.com>; Kaippallimalil John <john.kaippallimalil@futurewei= .com>
Cc: apn@ietf.org; Gengxuesong (G= eng Xuesong) <gengxuesong@huaw= ei.com>; Uma Chunduri <uma= c.ietf@gmail.com>; Lizhenbin <lizhenbin@huawei.com>; dmm <dmm@ietf.org>
Subject: Re: [Apn] [DMM] Regarding APN Usecase in Mobile Core

 

Many thanks to Sridhar and John= ‘s insightful description of GTP-u tunnel for both 4G and 5G.

IMHO, APN should focus on the 5= G case, i.e. potentially hundreds of thousands (or even millions) of GTP-u = tunnels between a pair of one gNB and one UPF.

I think two scenarios worth exp= loring further separately:

1= )   &= nbsp;  5G core can exchange si= gnal with the IP network (the N6 interface), more likely the 5G Core and N6= network are administrated by the same network operator.

a= .   &= nbsp;  5G core can tag the pac= kets before handing off to the N6 interface (i.e. the IP network), such as = inserting a metadata to the data packets

b= .   &= nbsp;  inform the IP network o= f the meaning of the inserted Metadata.

c= .   &= nbsp;  The IP network needs to= remove the metadata before handing the packets to their destinations<= /o:p>

 

2= )   &= nbsp;  There is no communicati= on between the 5G core and the IP network, then the IP network can only dep= end on the priority bits added by the UE, which can be very unpredictable.

 

The Section 4 (Mobility Packet = Transition in the Data Network) and the Section 5 (Transport Network charac= teristics Mapping to SR-TE Paths) have good description on how to extend 5G= core’s TN aware mobility information for various TE paths within IP networks. https://datatracker.ietf.org/doc/draft-mcd-rtgwg-extension-tn-aware-mobilit= y/

 

 

Linda Dunbar<= /p>

From: Apn <apn-bounces@iet= f.org> On Behalf Of Sridhar Bhaskaran
Sent: Thursday, January 21, 2021 10:39 PM
To: Kaippallimalil John <john.kaippallimalil@futurewei.com>
Cc: apn@ietf.org; Gengxuesong (G= eng Xuesong) <gengxuesong@huaw= ei.com>; Uma Chunduri <uma= c.ietf@gmail.com>; Lizhenbin <lizhenbin@huawei.com>; dmm <dmm@ietf.org>
Subject: Re: [Apn] [DMM] Regarding APN Usecase in Mobile Core

 

Hi Xuesong,

 

In addition to what John said, = in 3GPP networks there is one GTP-u tunnel per bearer (in case of 4G) and o= ne GTP-u tunnel per PDU session (in case of 5G).

 

One UE (user equipment - i.e mo= bile device) may have multiple PDU sessions and hence in the network there = may be more than one tunnel for a UE. The scope of GTP-u tunnel is from UPF= to gNB only. GTP-u does not go all the way upto UE. The GTP-u header has a field called "TEID" (tun= nel endpoint identifier). The TEID in the header identifies a context in UP= F and gNB. The context gets established through signalling plane. The conte= xt provides information on the QoS to be provided for the bearer,  PDCP ciphering keys applicable for the bearer contex= t etc.,. If there are a million UE that are getting connected to a UPF, the= re could be few million GTP-u tunnels (TEID).

 

In summary:

1. The 5QI / QFI marking in the= GTP-u extension header provides a lookup for the general QoS characteristi= c applicable for that 5QI

2. TEID in the GTP-u header pro= vides a lookup for UE and bearer specific contextual information for any di= fferentiated treatment.

 

Regards

Sridhar

 

On Fri, Jan 22, 2021 at 2:55 AM= Kaippallimalil John <john.kaippallimalil@futurewei.com> wrote:

Hi Xuesong,

 

Traffic policy for subscribers is managed per= PDU session at the UPF (and gNB).  

GTP-u does provide encapsulation between the = end points, but its control fields are meant for conveying control semantic= s between the GTP endpoints: they were not intended for IP transport/ traffic underlays. 5QI/QCI etc are in the G= TP extension header which may not be ideal to lookup to classify each packe= t in the transport network.

 

The entity that classifies data packets (upst= ream at gNB and downstream at UPF-PSA) also inserts the DSCP for that GTP p= acket. The classification is based on subscriber aspects but may also on be based on its content (e.g., using DP= I).

 

Best Regards,

John

 

 

From: dmm = <dmm-bounces@i= etf.org> On Behalf Of Gengxuesong (Geng Xuesong)
Sent: Wednesday, January 20, 2021 8:23 PM
To: Uma Chunduri <umac.ietf@gmail.com>; Lizhenbin <lizhenbin@huawei.com>
Cc: apn@ietf.org; dmm <dmm@ietf.org<= /a>>
Subject: Re: [DMM] [Apn] Regarding APN Usecase in Mobile Core

 

Hi Uma and all,

 

I have read the document and got a few questions:

In my understanding, in the UPF where traffic policy is enforced, the f= ine-granularity services are provided. Then what fields in the GTP-u encaps= ulation indicates the traffic's service requirements? When a GTP-u tunnel goes into a SRv6 policy, according to wh= ich fields in the GTP-u encapsulation the DSCP is generated? We know that t= here are parameters such as 5QI/QCI and QFI, whether they are associated wi= th a GTP-u tunnel?

 

Best

Xuesong

From: Apn = [mailto:apn-bounc= es@ietf.org] On Behalf Of Uma Chunduri
Sent: Tuesday, January 19, 2021 3:17 AM
To: Lizhenbin <lizhenbin@huawei.com>
Cc: apn@ietf.org; dmm <dmm@ietf.org<= /a>>
Subject: Re: [Apn] [DMM] Regarding APN Usecase in Mobile Core

 

Hi Robin,

 

In-line..

 

Cheers!
--

Uma C.

 

Hi APNers and DMMers,

I re= member that in the mobile core scenarios the GTP-u tunnel can be set up acc= ording to the user and application requirements, but I do not understand the details.

 

[Uma]: Obviously, the best reference for GTP-= U is TS 29.281. However, uou should look into https://datatracker.ietf.org/doc/draft-ietf-dmm-5g-uplane-an= alysis/ where lot more details and other references related this topic was an= alyzed (primarily started after/during REL-15, when  any other use pla= ne other than GTP-U is worthwhile is debated for 5G N9 interface).

 

I th= ink when the packet tunneled by GTP-u traverses the APN-based transport net= work, it may be mapped to the corresponding tunnel according to the user and application requirements to implement the= uniform service. If you are familiar with the principle of GTP-u in the mo= bile core, please help provide some details.&nb= sp;

&nbs= p;

&nbs= p;

Best= Regards,

Zhen= bin (Robin)

&nbs= p;

&nbs= p;

_____________________________________________= __
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

_______________________________= ________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm



--

=  o__
 _>  /__
(_) \(_)... Burn fat not fuel - Bike along to a healthier life and cleaner =
world! :)

Sridhar Bhaskaran

--_000_4278D47A901B3041A737953BAA078ADE19878637dggeml512mbschi_-- From nobody Thu Feb 11 16:26:51 2021 Return-Path: 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 04D993A0EC9; Thu, 11 Feb 2021 16:26:50 -0800 (PST) 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 q_06hl0rGPL3; Thu, 11 Feb 2021 16:26:48 -0800 (PST) Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (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 409963A0EC4; Thu, 11 Feb 2021 16:26:48 -0800 (PST) Received: by mail-yb1-xb31.google.com with SMTP id d184so7478684ybf.1; Thu, 11 Feb 2021 16:26:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=W4YWtqoxX7kWA5GUTy67ARTYW1OOv6ZCH7DDnBqJUWc=; b=TpK0gJJrlBhk0BP92ERnLubeSDqDU+Foa/OMqGSFIQpsx9FZlAXQcyVSeqUM9LwI4M Hsqmt7vbsSKSp8CJdvj0V77ioGc9MumcQH+HQejmaHZjGnX4TvDXK4/pQkXGecSI/5R+ X4gL/61Si2tPcLVajt+/bbdiEyFJpAfwSee9ks0wFdFhuQXOgk0QtwLAUqXFxzAfyLtX CqzbMz1QVkrR3QWZ4b+4LDQoKt8bYh8MIiFm+M+sJPGIVc/rm3LFt6kAqC19uW1ENVZy EFchlXIsLoFnnqxjUKJJ4ySB7R/WIePZIK+sDzgCR+tv0mka7mClKKd+Ok8S/25/LpHR YBZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=W4YWtqoxX7kWA5GUTy67ARTYW1OOv6ZCH7DDnBqJUWc=; b=tltarJRyzjnTqDgRzU35f0XYwTnzFbWHIiXWBFAlZOyU5gvcBoBEZ3XCNlOj0JJNnR ok8UogyIIAyGPAaj/OlaELmdJ+kF6ssPfh0i7aJsZIYzsyZFvDLk6pdz7Da8Tvsapq1w Cl3p2UG+9GzyY/ZYewnvz8WE4emYVEslvnKQ7FkzSdtMMkFMwVHqlrxDgpwuV90m1Ix7 oag96pRuTj3kFRhFV668NGVncwj+ZRUq9Nk68FzEyAqgXZBLxkOOOXZF76BitlFmVmvb 8eIK85VYCI9vuUvxhTl1/7hBTGQfVSdB0DNqyynUlLKTuLPbr4o40sLl61TNdEsA3zMA 0Kgw== X-Gm-Message-State: AOAM531jJ5+bBsLUn6QCOf54LyOiJdGOYL438NiZlhxH78rdSmgck9Rz hOwtOASeq2oQLGSxYLuPZnZRThummYS1JVpfaqEpPouaI+w= X-Google-Smtp-Source: ABdhPJzFYe9YkZ46JQnWKFTtYX7utgNW2Dm8O//bz/cwJUf/gVLVU3kkSrzB88VwzuN5S5btlj9lRm2XK6nI+17Whug= X-Received: by 2002:a25:538a:: with SMTP id h132mr608047ybb.247.1613089606579; Thu, 11 Feb 2021 16:26:46 -0800 (PST) MIME-Version: 1.0 From: Uma Chunduri Date: Thu, 11 Feb 2021 16:26:36 -0800 Message-ID: To: TEAS WG Cc: dmm Content-Type: multipart/alternative; boundary="000000000000fdba5505bb18b049" Archived-At: Subject: [DMM] draft-ietf-teas-ietf-network-slice-definition-00 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 00:26:50 -0000 --000000000000fdba5505bb18b049 Content-Type: text/plain; charset="UTF-8" Dear All, 2 questions on this draft: 1. Section 4.2 defines 'IETF Network Slice endpoints' It Says - " o They are conceptual points of connection of a consumer network, network function, device, or application to the IETF network slice. This might include routers, switches, firewalls, WAN, 4G/5G RAN nodes, 4G/5G Core nodes, application acceleration, Deep Packet Inspection (DPI), server load balancers, NAT44 [RFC3022 ], NAT64 [RFC6146 ], HTTP header enrichment functions, and TCP optimizers." I presume 4G/5G RAN nodes, you meant eNB, gNB-DU, gNB-CU-UP etc. If yes, there was a question from one of the 3GPP delegates on how this can be called as 'IETF Network Slice Endpoint'? I guess, we ought to be cognizant when we tag 'IETF' for some of these definitions. The above also mentions 4G/5G Core nodes aka SGW/PGW/all-variants-of-UPFs and these are again not typically 'IETF Network Slice Endpoints'. Could you please give your thoughts here? 2. Section 1 says "IETF network slices are created and managed within the scope of one or more network technologies (e.g., IP, MPLS, optical). : Obviously, optical is a bigger topic and if we talk about optical solutions like OTN (Layer 1) and SPN (Layer 1.5) are more controlled by other SDOs. SPN has a complete slicing solution with not much bearing to IETF. So, could you please expand 'optical' in the list above? Is it the various optical control plane specifications done here, you were referring to? -- Uma C. --000000000000fdba5505bb18b049 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,

2 questions on this draft:

1.=C2=A0
Section 4.2 defines 'IETF Net= work Slice endpoints'

It Says -

=
" o = They are conceptual points of connection of a consumer network,
      network functio=
n, device, or application to the IETF network
      slice.  This might include routers, switches, firewalls, WAN,
      4G/5G RAN nodes, 4G/5G Core nodes, application acceleration, Deep
      Packet Inspection (DPI), server load balancers, NAT44 [RFC3022],
      NAT64 [RFC6146], HTTP header enrichment functions, and=
 TCP
      optimizers."


I presume 4G/5G RAN =
nodes, you meant eNB, gNB-DU, gNB-CU-UP etc. If yes,
there was a question from one of the 3GP=
P delegates on how=C2=A0this can be called as 
'IETF Network Slice Endpoint'? 
<=
pre class=3D"gmail-newpage" style=3D"font-size:13.3333px;margin-top:0px;mar=
gin-bottom:0px;break-before:page;color:rgb(0,0,0)">
I guess, we ought to be cognizant whe=
n we tag 'IETF' for some of 
these definitions. 

The above also mentions 4G/5G Core nodes aka SGW/PGW/all-variants-o=
f-UPFs and 
these =
are again not typically 'IETF Network Slice Endpoints'.

Could you please give your thoughts here?<=
/pre>

2. 

Section 1 says

   or more networ=
k technologies (e.g., IP, MPLS, optical). :


=
Obviously, optical is a bigger topic and if we talk about optical solutions=
 like 
OTN (Layer =
1)  and SPN (Layer 1.5) are more controlled by other SDOs. SPN has 
a complete slicing soluti=
on with not much bearing to IETF. 

So, could you please expand 'op=
tical' in the list above? Is it the  various optical control plane 
specifications done here, you were ref=
erring to? 
=

--
Uma C.



--000000000000fdba5505bb18b049-- From nobody Fri Feb 12 06:46:59 2021 Return-Path: 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 0C46D3A16FD; Fri, 12 Feb 2021 06:46:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 Hv3_OOyUdAuD; Fri, 12 Feb 2021 06:46:52 -0800 (PST) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2111.outbound.protection.outlook.com [40.107.92.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAA773A16FC; Fri, 12 Feb 2021 06:46:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=D+G7wScYpfEihsivZO8KjEdMbo0Kq3h6etJyb91Q/7orxS7tUjQTmiuAKDI64ab2wd+wFOkz+lNYlOF4/UDuU0S75v/Kd+TlQ582T9FskMj4ntyaHGHlFmFW/ikNCt5BDkwcIrPy+eQTpjr26SD++mLS/kNEWTuhh/pktfem3CMnc/7u0pPVabnxl7/eIHuXAg5tfG175xUUDpXviWRpuUvQ4JrTnLZ2vS7QN9RhZLCX8fp7mmxU9FL5WpdRbm0Le5i7LQpqa5oT2MRKhgl3shNR7xsUatqCEI+NWJ95TYyIVRuC28Imyr+U4YO92pgsjUjxxNWB6uEoD40b8ICxRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Slkgx9fzvWSVbDKIIeoc8s+bx5X1fkY4v3oMwJYf+Ew=; b=fkCp/FogyNa478WJGwC0GremGvsjsCjviay68zCy+OA3gXOLypXUDL0NGzeX/7vDfEuZScs2kLKk9Qvdzt/lxToBA1o/oTp8fVp3C/TSNqMOIetvKpcKUJwzmJsYIBIx51juNAZ00vjEqJRhCjMIAPDeldYuX2e/GqwQz93PewCRC1t/ZkAyOlICbu/E1XlkLg3I7ZX4Afgfi/qsKxHJxFlLOP0G0vUkq6aAthznRSF89HIme5WZbsY87wXlzmZ5Za2z/RUKmy3kd5rZvx/0ZemD6h3rec0QaBi36EMjo/VSOXKyAYbuIBA5Oudcp40KnZGIAJf6hGI7//CYhhoQlA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Slkgx9fzvWSVbDKIIeoc8s+bx5X1fkY4v3oMwJYf+Ew=; b=lIylNrxnaR6QdK5DqRviwygKM/sIli4Pv3vxP9aURGKXf2v5Tjh322d1CeYNUZIfFrs16dy2FzV0YaTzLwT5pjfbJ7vCRIb/HQD8TSulPhuy5Lzvhm9/+DPn/G9lNdBvzQwfvZ4Hf+GAU5clJGQwwKLANlal1AIrMUMpGuCqHtE= Received: from BN6PR08MB2707.namprd08.prod.outlook.com (2603:10b6:404:c0::10) by BN6PR08MB3313.namprd08.prod.outlook.com (2603:10b6:405:68::36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.27; Fri, 12 Feb 2021 14:46:48 +0000 Received: from BN6PR08MB2707.namprd08.prod.outlook.com ([fe80::bcda:a2e1:1f5d:b93f]) by BN6PR08MB2707.namprd08.prod.outlook.com ([fe80::bcda:a2e1:1f5d:b93f%3]) with mapi id 15.20.3846.034; Fri, 12 Feb 2021 14:46:48 +0000 From: "Rokui, Reza (Nokia - CA/Ottawa)" To: Uma Chunduri , TEAS WG CC: dmm Thread-Topic: [Teas] draft-ietf-teas-ietf-network-slice-definition-00 Thread-Index: AQHXAU3jK7plZc+OQ0eNkuaustw67w== Date: Fri, 12 Feb 2021 14:46:48 +0000 Message-ID: <9968BDC1-BD7B-4305-8856-C71495BEA378@nokia.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.45.21011103 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [24.246.4.36] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 1dc415c6-05db-4a62-3b13-08d8cf650698 x-ms-traffictypediagnostic: BN6PR08MB3313: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: iWgtBCJrvrIsWHU4Z6qEajONZ3wvQNEWweaXbpDmZDY4db0kadahwdH8BH6D8C5hLV4HYwsdXdq0S/AQ2uL3sL8o6Ddda1TLgt3fAWUIrpBZIxzeRj7vV5/LPOhQzujkbfwkX/nnXvwHNy3o4f2t/9UWPIypt3np+VGVazc7AHbCeQBavmPPE3rysylKEadZN85bPm6+dJa74ICCFtSQUHhDMw9KCc2+85qHqVDtOaZc7L+Et2oV0MOTD0vhy14urxnCIzKXy1P1oSyuWqLqpWppneQ1h34sBvWaU5O44CfgZzxQg6Gkw3OIRQWdclIh4CZEzJUiidyEY3JpyAMYAqYC5LW+oFOeiFpSN9ma85/zFS+jgn4UmeqJWEItQLZPv0DODlBZQ43pntTTBJLiO5HiNvadfMfXfMGGOHB5rurD0Io4cLLmbB2FnfCfLgq1dhJacWEpygiCVZT0ZeG6uMHdyfTxXZo43d7VhtrqfNbxLlnLzSxCVYyiiGo+fVGkxdr01OGF2UPRYVyvZO8TtWE0Jm8ukNwkTWPu9AqF0BauxudSB/JkRIKt1F5hLiRpP/IVJkLwrDFPsXuZNwo1yBTw/Naf+jmY7Bv461scxvBp0HvMWJrABgzSAlIS/JF9uumO7nnr2MuBw8Ms18nv8A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN6PR08MB2707.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(396003)(136003)(376002)(346002)(39860400002)(5660300002)(26005)(6486002)(9326002)(8936002)(86362001)(478600001)(2616005)(91956017)(316002)(186003)(83380400001)(6512007)(4326008)(66946007)(36756003)(166002)(2906002)(8676002)(53546011)(64756008)(71200400001)(33656002)(66476007)(6506007)(66556008)(76116006)(66446008)(110136005)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?cUxLTmtETXdYNkcxYkxDU1RXc2I1NWxRUDFmRGI5UG9kWkNrbHZXcm4yVEp1?= =?utf-8?B?NG1XcUhuaVgyZFJEWFQ3bEE2NnhVOVdleTZiMlFNR1Z5a21KZ21NdDJtNDdG?= =?utf-8?B?VlUxK3J3V3FFU01aOUpyWmhodEpjZFNBWU1EWFR5QTBZcnNaY2pqL2ROMEhK?= =?utf-8?B?djFUUC9VekM5Y0hYMmc4R2FiZHBrWUZhMkdLUE9KZ25wVW9pK2Mzcy8yMHZX?= =?utf-8?B?Ulp3TjRXSmxrNUJlakFYRTF0VGZqWHNHbEQ4cE1GeGZVRXpJTmtJQkEzUzZH?= =?utf-8?B?Mzd6emxrbE13NFUrRnRwRDlla2JLNXVDTmlhdldlM2pqeWdYak1NeHdNbFdo?= =?utf-8?B?Vk1jUTFFdkxUSzBnMm1jTnIwRVMyZmdncUF0QWhBRk9CbTBET1pHWlBRQWgw?= =?utf-8?B?c3BrTEsreFBKcDVESkdST28rUlowL3hxUGJYcDVja1JsaldFT2cvVzh1eVhh?= =?utf-8?B?VXQva3gydUh3Q2VNaStHNXc3UnVaeFQzUncwYnRBRkR3MzNJSGY1M2taRzY3?= =?utf-8?B?WkhjRnFnYTZ3M2Jsd1RVWjRCais2WWJ5amxUUWJsSENjRDk0d0E5dFhIV2hq?= =?utf-8?B?YlNvdVBRWnBMampGZ2dkTHJiN1gxK0REYURZVXh1ZS9pZ1FLQi9FRzZCSTlT?= =?utf-8?B?Vy9mcUhZaTVCZ3p4MVNpallMS1RZZ2pCbDNvZjlWZVU0TjZ3YmhUblg3NEg1?= =?utf-8?B?ZTBQeE1rNld5eHdFRFgyMFZVcDhZQjJRTUtvVzJUU1huQzRaY1EvQVUrU2Rz?= =?utf-8?B?d1o4VEFuNmtidS83VThoaW01MzIzRmxmd1JLVkliNkV4MlQwalhyS0dEd3l1?= =?utf-8?B?bU5wbXVRY3pncWxvTml1cFBYRE53VXdpTlRTV0VMQm44TmxDbk5IRlUrcmp6?= =?utf-8?B?a29WdEVYbGkwaVZBazlKOXRpU3h6RE1ZSVBNTTF0VWdYck1PNGVtOGJyNHlv?= =?utf-8?B?WEpzSW8xUkJYdDN4NzllZ0Z6azRjbHNyS0J6empHeTZJSmp2cHZwdFlLSGpK?= =?utf-8?B?bm9pZGFubmFaK0FkbVl3MU5qbEpiZktLOUdxZkF0U1ZwZmtiNTBvNTRlYXdo?= =?utf-8?B?WWJXR21VQjE5enNPamZ5UlU3UlFkUHpsUWJUSEhpMEZMUU05RGFMWGVBNjAw?= =?utf-8?B?RUxLbVJBQnpIVWY4aHlrZVB3dU9zcUdWZXRpVDd6dmtSYkV4K09OLzdSZTFy?= =?utf-8?B?ZG0ya2QwZXh6Mm1UVytQenJxUXpEOG1oMnEyWU5zYkk5clVMZ0lMRzZQcXVh?= =?utf-8?B?Z0ZkWDB6bEVWSGhuYUxiMmg1QitERFJoQ0JkaHZ6aWxWL3lWLzVneWVaakRI?= =?utf-8?B?NURSWnEwb2dUaDIzNVJGQXdJWHJscHdYWUdxdm1JRW9KR1NMejZ4WXJhSlEv?= =?utf-8?B?V0FJK2FWakYyV2F1Z0FLakRRRnZqT0RTRUFpMTIrYWhrdm9kdmRta25OMkJj?= =?utf-8?B?elNVNUgvYUxDU1pGbmJoRlp4MjltVzNFdHprSjV4VEh3endJaENBazdSQmR4?= =?utf-8?B?aFJScWEzbXdYYnNtWnlWY3hQeVV3RFFxK21jUGVxcUpBRnNJUlVMQ01XdkMz?= =?utf-8?B?dkF5dWFWeWxiQlJXcm1pYlNpTE8zZTVoYStSaDhKUEgrM1piZHNGSm43dXla?= =?utf-8?B?TmZsdkdCdm41TVdnK01KTHFwYXdZNDYxTGdXRjRxRzFwNEFYQTVWNjY1YmIz?= =?utf-8?B?TEZLWEJpNm41b1VOOEp5VkFWQnNPWTNtdnpHakxqa0NWZkRDV0pMTnQydlJq?= =?utf-8?Q?IxvdocavTSIKFyzH+8te3Zn4UC9YA1c45M0k3Sv?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_9968BDC1BD7B43058856C71495BEA378nokiacom_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN6PR08MB2707.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1dc415c6-05db-4a62-3b13-08d8cf650698 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2021 14:46:48.0762 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: sjbiq+kefIn8XD4kEBlsJEwJHXsa5mbCXDsqL+uVMux1uuafCI8dPZmrwiCJWJPij2OVMZc1ckg5gx0/bv2i1w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR08MB3313 Archived-At: Subject: Re: [DMM] [Teas] draft-ietf-teas-ietf-network-slice-definition-00 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 14:46:54 -0000 --_000_9968BDC1BD7B43058856C71495BEA378nokiacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVW1hLA0KVGhlIGNvbW1lbnRzIGFyZSBpbmxpbmVkLg0KDQpSZXphDQoNCg0KDQpGcm9tOiBU ZWFzIDx0ZWFzLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBVbWEgQ2h1bmR1cmkgPHVt YWMuaWV0ZkBnbWFpbC5jb20+DQpEYXRlOiBUaHVyc2RheSwgRmVicnVhcnkgMTEsIDIwMjEgYXQg NzoyNiBQTQ0KVG86IFRFQVMgV0cgPHRlYXNAaWV0Zi5vcmc+DQpDYzogZG1tIDxkbW1AaWV0Zi5v cmc+DQpTdWJqZWN0OiBbVGVhc10gZHJhZnQtaWV0Zi10ZWFzLWlldGYtbmV0d29yay1zbGljZS1k ZWZpbml0aW9uLTAwDQoNCkRlYXIgQWxsLA0KDQoyIHF1ZXN0aW9ucyBvbiB0aGlzIGRyYWZ0Og0K DQoxLg0KU2VjdGlvbiA0LjIgZGVmaW5lcyAnSUVURiBOZXR3b3JrIFNsaWNlIGVuZHBvaW50cycN Cg0KSXQgU2F5cyAtDQoNCiIgbyBUaGV5IGFyZSBjb25jZXB0dWFsIHBvaW50cyBvZiBjb25uZWN0 aW9uIG9mIGEgY29uc3VtZXIgbmV0d29yaywNCg0KICAgICAgbmV0d29yayBmdW5jdGlvbiwgZGV2 aWNlLCBvciBhcHBsaWNhdGlvbiB0byB0aGUgSUVURiBuZXR3b3JrDQoNCiAgICAgIHNsaWNlLiAg VGhpcyBtaWdodCBpbmNsdWRlIHJvdXRlcnMsIHN3aXRjaGVzLCBmaXJld2FsbHMsIFdBTiwNCg0K ICAgICAgNEcvNUcgUkFOIG5vZGVzLCA0Ry81RyBDb3JlIG5vZGVzLCBhcHBsaWNhdGlvbiBhY2Nl bGVyYXRpb24sIERlZXANCg0KICAgICAgUGFja2V0IEluc3BlY3Rpb24gKERQSSksIHNlcnZlciBs b2FkIGJhbGFuY2VycywgTkFUNDQgW1JGQzMwMjI8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzMwMjI+XSwNCg0KICAgICAgTkFUNjQgW1JGQzYxNDY8aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzYxNDY+XSwgSFRUUCBoZWFkZXIgZW5yaWNobWVudCBmdW5jdGlvbnMsIGFuZCBU Q1ANCg0KICAgICAgb3B0aW1pemVycy4iDQoNCg0KDQoNCg0KSSBwcmVzdW1lIDRHLzVHIFJBTiBu b2RlcywgeW91IG1lYW50IGVOQiwgZ05CLURVLCBnTkItQ1UtVVAgZXRjLiBJZiB5ZXMsDQoNCnRo ZXJlIHdhcyBhIHF1ZXN0aW9uIGZyb20gb25lIG9mIHRoZSAzR1BQIGRlbGVnYXRlcyBvbiBob3cg dGhpcyBjYW4gYmUgY2FsbGVkIGFzDQoNCidJRVRGIE5ldHdvcmsgU2xpY2UgRW5kcG9pbnQnPw0K DQoNCg0KW1JlemFdIFllcyA0Ry81RyBSQU4gbm9kZXMgbWVhbnMgZU5CLCBnTkItRFUsIGdOQi1D VS1VUCBldGMuIEhvd2V2ZXIsIHRoZSBmdW5kYW1lbnRhbCBhc3BlY3QgdG8gYmUgY29uc2lkZXJl ZCBmb3IgSUVURiBOZXR3b3JrIFNsaWNlIGlzIHRoYXQgaXQgaXMgdGVjaG5vbG9neS1hZ29uaXN0 aWMuDQoNCk5vdGUgdGhhdCBhbHNvIHRoYXQgUkFOIG5vZGVzIGZvciBleGFtcGxlIGhhdmUgdHdv IGxvZ2ljYWwgY29tcG9uZW50czsgUmFkaW8gY29tcG9uZW50cyBhbmQgdHJhbnNwb3J0IGNvbXBv bmVudC4gVGhlIElFVEYgTmV0d29yayBTbGljZSBhZGRyZXNzZXMgdGhlIGNvbm5lY3Rpdml0eSBm cm9tIFRyYW5zcG9ydCBjb21wb25lbnQgb2YgUkFOICh3aGljaCBpbiB0b2RheeKAmXMgdGVjaG5v bG9neSBpdCBpcyB0aGUgZGF0YS1wYXRoKSB0byBvdGhlciBlbmRwb2ludHMuIEl0IGlzIGNhbGxl ZCAnSUVURiBOZXR3b3JrIFNsaWNlIEVuZHBvaW50JyBiZWNhdXNlIHVzZXLigJlzIHRyYWZmaWMg c3RhcnRzIGZyb20gdGhpcyBlbnRyeSBwb2ludC4NCg0KDQoNCkkgZ3Vlc3MsIHdlIG91Z2h0IHRv IGJlIGNvZ25pemFudCB3aGVuIHdlIHRhZyAnSUVURicgZm9yIHNvbWUgb2YNCg0KdGhlc2UgZGVm aW5pdGlvbnMuDQoNCg0KDQpUaGUgYWJvdmUgYWxzbyBtZW50aW9ucyA0Ry81RyBDb3JlIG5vZGVz IGFrYSBTR1cvUEdXL2FsbC12YXJpYW50cy1vZi1VUEZzIGFuZA0KDQp0aGVzZSBhcmUgYWdhaW4g bm90IHR5cGljYWxseSAnSUVURiBOZXR3b3JrIFNsaWNlIEVuZHBvaW50cycuDQoNCltSZXphXSBB cyBtZW50aW9uZWQgYWJvdmUgdGhlICdJRVRGIE5ldHdvcmsgU2xpY2UgIGFuZCAnSUVURiBOZXR3 b3JrIFNsaWNlIEVuZHBvaW50IGFyZSB0ZWNobm9sb2d5LWFnbm9zdGljcy4gSW4gZHJhZnQgdGhl c2Ugbm9kZXMgYXJlIGFyZSBjYWxsZWQgREFOIChEZXZpY2UsIEFwcGxpY2F0aW9uLCBORikgd2hp Y2ggc2hvd3MgaXRzIHRydWUgdGVjaG5vbG9neS1hZ25vc3RpY3MuDQoNCg0KDQpDb3VsZCB5b3Ug cGxlYXNlIGdpdmUgeW91ciB0aG91Z2h0cyBoZXJlPw0KDQpbUmV6YV0NCg0KDQoNCjIuDQoNCg0K DQpTZWN0aW9uIDEgc2F5cw0KDQoNCg0KIklFVEYgbmV0d29yayBzbGljZXMgYXJlIGNyZWF0ZWQg YW5kIG1hbmFnZWQgd2l0aGluIHRoZSBzY29wZSBvZiBvbmUNCg0KICAgb3IgbW9yZSBuZXR3b3Jr IHRlY2hub2xvZ2llcyAoZS5nLiwgSVAsIE1QTFMsIG9wdGljYWwpLiA6DQoNCg0KDQoNCg0KT2J2 aW91c2x5LCBvcHRpY2FsIGlzIGEgYmlnZ2VyIHRvcGljIGFuZCBpZiB3ZSB0YWxrIGFib3V0IG9w dGljYWwgc29sdXRpb25zIGxpa2UNCg0KT1ROIChMYXllciAxKSAgYW5kIFNQTiAoTGF5ZXIgMS41 KSBhcmUgbW9yZSBjb250cm9sbGVkIGJ5IG90aGVyIFNET3MuIFNQTiBoYXMNCg0KYSBjb21wbGV0 ZSBzbGljaW5nIHNvbHV0aW9uIHdpdGggbm90IG11Y2ggYmVhcmluZyB0byBJRVRGLg0KDQoNCg0K U28sIGNvdWxkIHlvdSBwbGVhc2UgZXhwYW5kICdvcHRpY2FsJyBpbiB0aGUgbGlzdCBhYm92ZT8g SXMgaXQgdGhlICB2YXJpb3VzIG9wdGljYWwgY29udHJvbCBwbGFuZQ0KDQpzcGVjaWZpY2F0aW9u cyBkb25lIGhlcmUsIHlvdSB3ZXJlIHJlZmVycmluZyB0bz8NCg0KDQoNCi0tDQoNClVtYSBDLg0K DQoNCg0KDQoNCg0K --_000_9968BDC1BD7B43058856C71495BEA378nokiacom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFz Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow Y207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh ciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uSFRNTFByZWZvcm1hdHRl ZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0K CWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1DQSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5 bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiNDMDAw MDAiPkhpIFVtYSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiNDMDAwMDAiPlRoZSBjb21tZW50cyBhcmUg aW5saW5lZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiNDMDAwMDAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Y29sb3I6I0MwMDAwMCI+UmV6YTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJs YWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj5UZWFzICZsdDt0ZWFzLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBV bWEgQ2h1bmR1cmkgJmx0O3VtYWMuaWV0ZkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9i PlRodXJzZGF5LCBGZWJydWFyeSAxMSwgMjAyMSBhdCA3OjI2IFBNPGJyPg0KPGI+VG86IDwvYj5U RUFTIFdHICZsdDt0ZWFzQGlldGYub3JnJmd0Ozxicj4NCjxiPkNjOiA8L2I+ZG1tICZsdDtkbW1A aWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPltUZWFzXSBkcmFmdC1pZXRmLXRlYXMt aWV0Zi1uZXR3b3JrLXNsaWNlLWRlZmluaXRpb24tMDA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRlYXIgQWxsLDxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MiBxdWVzdGlvbnMgb24gdGhpcyBk cmFmdDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+MS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlNlY3Rpb24gNC4yIGRlZmluZXMgJ0lFVEYgTmV0d29yayBTbGljZSBlbmRwb2ludHMn PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0 IFNheXMgLTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mcXVvdDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+IG8g VGhleSBhcmUgY29uY2VwdHVhbCBwb2ludHMgb2YgY29ubmVjdGlvbiBvZiBhIGNvbnN1bWVyIG5l dHdvcmssPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cHJlIHN0eWxlPSJicmVhay1i ZWZvcmU6cGFnZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgbmV0d29yayBmdW5jdGlvbiwgZGV2aWNlLCBvciBhcHBsaWNhdGlvbiB0byB0 aGUgSUVURiBuZXR3b3JrPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNsaWNlLiZuYnNw OyBUaGlzIG1pZ2h0IGluY2x1ZGUgcm91dGVycywgc3dpdGNoZXMsIGZpcmV3YWxscywgV0FOLDxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA0Ry81RyBSQU4gbm9kZXMsIDRHLzVHIENvcmUg bm9kZXMsIGFwcGxpY2F0aW9uIGFjY2VsZXJhdGlvbiwgRGVlcDxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBQYWNrZXQgSW5zcGVjdGlvbiAoRFBJKSwgc2VydmVyIGxvYWQgYmFsYW5jZXJz LCBOQVQ0NCBbPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzMwMjIiIHRp dGxlPSImcXVvdDtUcmFkaXRpb25hbCBJUCBOZXR3b3JrIEFkZHJlc3MgVHJhbnNsYXRvciAoVHJh ZGl0aW9uYWwgTkFUKSZxdW90OyI+UkZDMzAyMjwvYT5dLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBOQVQ2NCBbPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzYx NDYiIHRpdGxlPSImcXVvdDtTdGF0ZWZ1bCBOQVQ2NDogTmV0d29yayBBZGRyZXNzIGFuZCBQcm90 b2NvbCBUcmFuc2xhdGlvbiBmcm9tIElQdjYgQ2xpZW50cyB0byBJUHY0IFNlcnZlcnMmcXVvdDsi PlJGQzYxNDY8L2E+XSwgSFRUUCBoZWFkZXIgZW5yaWNobWVudCBmdW5jdGlvbnMsIGFuZCBUQ1A8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb3B0aW1pemVycy4mcXVvdDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTpwYWdlIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHls ZT0iYnJlYWstYmVmb3JlOnBhZ2UiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJicmVhay1iZWZvcmU6cGFnZSI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5JIHByZXN1bWUgNEcvNUcgUkFOIG5vZGVzLCB5b3UgbWVh bnQgZU5CLCBnTkItRFUsIGdOQi1DVS1VUCBldGMuIElmIHllcyw8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTpwYWdlIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPnRoZXJlIHdhcyBhIHF1ZXN0aW9uIGZyb20gb25lIG9mIHRoZSAzR1BQIGRlbGVnYXRl cyBvbiBob3cmbmJzcDt0aGlzIGNhbiBiZSBjYWxsZWQgYXMgPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlIHN0eWxlPSJicmVhay1iZWZvcmU6cGFnZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4nSUVURiBOZXR3b3JrIFNsaWNlIEVuZHBvaW50Jz8gPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojQzAwMDAwIj5bUmV6YV0gWWVzIDRHLzVHIFJB TiBub2RlcyBtZWFucyBlTkIsIGdOQi1EVSwgZ05CLUNVLVVQIGV0Yy4gSG93ZXZlciwgdGhlIGZ1 bmRhbWVudGFsIGFzcGVjdCB0byBiZSBjb25zaWRlcmVkIGZvciBJRVRGIE5ldHdvcmsgU2xpY2Ug aXMgdGhhdCBpdCBpcyB0ZWNobm9sb2d5LWFnb25pc3RpYy48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiNDMDAwMDAiPk5vdGUgdGhhdCBhbHNvIHRo YXQgUkFOIG5vZGVzIGZvciBleGFtcGxlIGhhdmUgdHdvIGxvZ2ljYWwgY29tcG9uZW50czsgUmFk aW8gY29tcG9uZW50cyBhbmQgdHJhbnNwb3J0IGNvbXBvbmVudC4gVGhlIElFVEYgTmV0d29yayBT bGljZSBhZGRyZXNzZXMgdGhlIGNvbm5lY3Rpdml0eSBmcm9tIDx1PlRyYW5zcG9ydCBjb21wb25l bnQgb2YgUkFOPC91PiAod2hpY2ggaW4gdG9kYXnigJlzIHRlY2hub2xvZ3kgaXQgaXMgdGhlIGRh dGEtcGF0aCkgdG8gb3RoZXIgZW5kcG9pbnRzLiBJdCBpcyBjYWxsZWQgJ0lFVEYgTmV0d29yayBT bGljZSBFbmRwb2ludCcgYmVjYXVzZSB1c2Vy4oCZcyB0cmFmZmljIHN0YXJ0cyBmcm9tIHRoaXMg ZW50cnkgcG9pbnQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJi cmVhay1iZWZvcmU6cGFnZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5JIGd1ZXNzLCB3ZSBv dWdodCB0byBiZSBjb2duaXphbnQgd2hlbiB3ZSB0YWcgJ0lFVEYnIGZvciBzb21lIG9mIDxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0iYnJlYWstYmVmb3JlOnBhZ2UiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+dGhlc2UgZGVmaW5pdGlvbnMuIDxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZSBzdHlsZT0iYnJlYWstYmVmb3JlOnBhZ2UiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJicmVh ay1iZWZvcmU6cGFnZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGUgYWJvdmUgYWxzbyBt ZW50aW9ucyA0Ry81RyBDb3JlIG5vZGVzIGFrYSBTR1cvUEdXL2FsbC12YXJpYW50cy1vZi1VUEZz IGFuZCA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTpw YWdlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPnRoZXNlIGFyZSBhZ2FpbiBub3QgdHlwaWNh bGx5ICdJRVRGIE5ldHdvcmsgU2xpY2UgRW5kcG9pbnRzJy48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTpwYWdlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 I0MwMDAwMCI+W1JlemFdIEFzIG1lbnRpb25lZCBhYm92ZSB0aGUgJ0lFVEYgTmV0d29yayBTbGlj ZSZuYnNwOyBhbmQgJ0lFVEYgTmV0d29yayBTbGljZSBFbmRwb2ludCBhcmUgdGVjaG5vbG9neS1h Z25vc3RpY3MuIEluIGRyYWZ0IHRoZXNlIG5vZGVzIGFyZSBhcmUgY2FsbGVkIERBTiAoRGV2aWNl LCBBcHBsaWNhdGlvbiwgTkYpIHdoaWNoIHNob3dzIGl0cyB0cnVlIHRlY2hub2xvZ3ktYWdub3N0 aWNzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6I0Mw MDAwMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Q291bGQgeW91IHBsZWFzZSBnaXZlIHlvdXIgdGhvdWdodHMgaGVyZT88bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5bUmV6YV08bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTpwYWdlIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBz dHlsZT0iYnJlYWstYmVmb3JlOnBhZ2UiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Mi4gPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJicmVhay1iZWZvcmU6cGFnZSI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmUgc3R5bGU9ImJyZWFrLWJlZm9yZTpwYWdlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlNl Y3Rpb24gMSBzYXlzPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJicmVhay1i ZWZvcmU6cGFnZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTpwYWdlIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZxdW90O0lFVEYgbmV0d29yayBzbGljZXMgYXJlIGNyZWF0ZWQgYW5kIG1h bmFnZWQgd2l0aGluIHRoZSBzY29wZSBvZiBvbmU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmUgc3R5bGU9ImJyZWFrLWJlZm9yZTpwYWdlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyBvciBtb3JlIG5ldHdvcmsgdGVjaG5vbG9naWVzIChlLmcuLCBJUCwgTVBMUywg b3B0aWNhbCkuIDo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImJyZWFrLWJl Zm9yZTpwYWdlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZSBzdHlsZT0iYnJlYWstYmVmb3JlOnBhZ2UiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJi cmVhay1iZWZvcmU6cGFnZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5PYnZpb3VzbHksIG9w dGljYWwgaXMgYSBiaWdnZXIgdG9waWMgYW5kIGlmIHdlIHRhbGsgYWJvdXQgb3B0aWNhbCBzb2x1 dGlvbnMgbGlrZSA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImJyZWFrLWJl Zm9yZTpwYWdlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk9UTiAoTGF5ZXIgMSkmbmJzcDsg YW5kIFNQTiAoTGF5ZXIgMS41KSBhcmUgbW9yZSBjb250cm9sbGVkIGJ5IG90aGVyIFNET3MuIFNQ TiBoYXMgPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJicmVhay1iZWZvcmU6 cGFnZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5hIGNvbXBsZXRlIHNsaWNpbmcgc29sdXRp b24gd2l0aCBub3QgbXVjaCBiZWFyaW5nIHRvIElFVEYuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZSBzdHlsZT0iYnJlYWstYmVmb3JlOnBhZ2UiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJicmVhay1iZWZv cmU6cGFnZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5TbywgY291bGQgeW91IHBsZWFzZSBl eHBhbmQgJ29wdGljYWwnIGluIHRoZSBsaXN0IGFib3ZlPyBJcyBpdCB0aGUmbmJzcDsgdmFyaW91 cyBvcHRpY2FsIGNvbnRyb2wgcGxhbmUgPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0 eWxlPSJicmVhay1iZWZvcmU6cGFnZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5zcGVjaWZp Y2F0aW9ucyBkb25lIGhlcmUsIHlvdSB3ZXJlIHJlZmVycmluZyB0bz8gPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJicmVhay1iZWZvcmU6cGFnZSI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImJy ZWFrLWJlZm9yZTpwYWdlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPi0tPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJicmVhay1iZWZvcmU6cGFnZSI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj5VbWEgQy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9 ImJyZWFrLWJlZm9yZTpwYWdlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0iYnJlYWstYmVmb3JlOnBhZ2UiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJl IHN0eWxlPSJicmVhay1iZWZvcmU6cGFnZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_9968BDC1BD7B43058856C71495BEA378nokiacom_-- From nobody Fri Feb 12 15:02:30 2021 Return-Path: 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 244CF3A105F; Fri, 12 Feb 2021 15:02:24 -0800 (PST) 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 Z15zOWVjR4gw; Fri, 12 Feb 2021 15:02:21 -0800 (PST) Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (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 C13C63A0BDC; Fri, 12 Feb 2021 15:02:21 -0800 (PST) Received: by mail-yb1-xb2e.google.com with SMTP id p193so1046550yba.4; Fri, 12 Feb 2021 15:02:21 -0800 (PST) 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=KCShdy2Vf1JxuzbdJRFOppuqL82gBedy8UUv+8jJtzs=; b=dJUQEmqvBQAxWTbnWbKjEJiWMcFNI3qfAJ3TNnI5lq85+KD8str/asv+E/FBxCq2Qg dFGFKylt7kP6v26yUToLQUoxHBE/fPpvWY8PPwd4I3TmJLt4z6A87BjEt95gb1X1CAq/ PLoUFS4c7bBo82KptILgeUNvO/yav57ZuXi39WTlM6H5YzuJePRuwLNvDAT6GZw7SNq6 vaSZNt9caCaw935U1lBTU0qpkx5qBRBUpuS0SI3mgp/BlyiYQ2Lqxog5gIE9dg0cfW33 PD6q7KgSM47cAQmUtEqe5V9jPArp9BXpEE7zlMQlF3Sq1crV3EEz2mgfsz3q/cg8Ck5L sfAQ== 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=KCShdy2Vf1JxuzbdJRFOppuqL82gBedy8UUv+8jJtzs=; b=k+qtG6lfrddRLC0yZlo+WWGz/qql3EhgKk+8Pf4g/rgicw6gbNrq5ViYmOjlzg1wQd MjN4A9/xytHhptQztLZrg73FQqskXRbydDe1Oc/csjFxVbQZghGkFfBthReQRCoorz4K QvmxbEYTHhgLhc2E+PxqBnACmAfhLho47TEp4+mGfrQS9zA7UL7/mZglBTZ3M81bFV4a vH24Il/svnV8hnEVJoHxKZwzRtiFXqI9jTNWMX2TaEbVhH+gDlgR/VDcdSJzG5UHHt8W ztF1yJKmD9mzGI4O5+N6NTr/cNppaHSzSgdx9QSzoN5KZj5wZpyRH7XLR04OA92x/W15 W6lg== X-Gm-Message-State: AOAM5334cWmszopLLo6lfhQD7ZTiHM72s7hTW7Xb59jEM9UmlCroiAjj nSzoAMVOJFj8K3SlCUmkVCaB77NAjhS2mCjiV5FJnUSrvQI= X-Google-Smtp-Source: ABdhPJztQCxjhKViOpO7rQ0toEFbMFOcHkJ6bui6tGbMmaUmzTwgVhHQ+UoK6Xi1kE+LUrral1xrbjhlzlUYV4Waet4= X-Received: by 2002:a25:3104:: with SMTP id x4mr7082649ybx.141.1613170940904; Fri, 12 Feb 2021 15:02:20 -0800 (PST) MIME-Version: 1.0 References: <9968BDC1-BD7B-4305-8856-C71495BEA378@nokia.com> In-Reply-To: <9968BDC1-BD7B-4305-8856-C71495BEA378@nokia.com> From: Uma Chunduri Date: Fri, 12 Feb 2021 15:02:09 -0800 Message-ID: To: "Rokui, Reza (Nokia - CA/Ottawa)" Cc: TEAS WG , dmm Content-Type: multipart/alternative; boundary="000000000000e5085b05bb2ba077" Archived-At: Subject: Re: [DMM] [Teas] draft-ietf-teas-ietf-network-slice-definition-00 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 23:02:24 -0000 --000000000000e5085b05bb2ba077 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Reza, Many thx for your reply. See a quick response in-line. -- Uma C. On Fri, Feb 12, 2021 at 6:46 AM Rokui, Reza (Nokia - CA/Ottawa) < reza.rokui@nokia.com> wrote: > Hi Uma, > > The comments are inlined. > > > > Reza > > > > > > > > *From: *Teas on behalf of Uma Chunduri < > umac.ietf@gmail.com> > *Date: *Thursday, February 11, 2021 at 7:26 PM > *To: *TEAS WG > *Cc: *dmm > *Subject: *[Teas] draft-ietf-teas-ietf-network-slice-definition-00 > > > > Dear All, > > > > 2 questions on this draft: > > > > 1. > > Section 4.2 defines 'IETF Network Slice endpoints' > > > > It Says - > > > > " o They are conceptual points of connection of a consumer network, > > network function, device, or application to the IETF network > > slice. This might include routers, switches, firewalls, WAN, > > 4G/5G RAN nodes, 4G/5G Core nodes, application acceleration, Deep > > Packet Inspection (DPI), server load balancers, NAT44 [RFC3022 ], > > NAT64 [RFC6146 ], HTTP header = enrichment functions, and TCP > > optimizers." > > > > > > I presume 4G/5G RAN nodes, you meant eNB, gNB-DU, gNB-CU-UP etc. If yes, > > there was a question from one of the 3GPP delegates on how this can be ca= lled as > > 'IETF Network Slice Endpoint'? > > > > [Reza] Yes 4G/5G RAN nodes means eNB, gNB-DU, gNB-CU-UP etc. However, the= fundamental aspect to be considered for IETF Network Slice is that it is t= echnology-agonistic. > > Note that also that RAN nodes for example have two logical components; Ra= dio components and transport component. The IETF Network Slice addresses th= e connectivity from *Transport component of RAN* > > (which in today=E2=80=99s technology it is the data-path) to other endpo= ints. It is called 'IETF Network Slice Endpoint' because user=E2=80=99s tra= ffic starts from this entry point. > > * [Uma]: Indeed and in all these cases i.e., between DU-CU, gNB-UPF or eNB-SGW, SGW-PGW, UPF-UPF the packet emitted would be UDP/IP packet encapsulating the user payload with the overlay header. But just because it is emitting the IP packet we might not want to rename these as 'IETF Network Slice Endpoint'. As we are speaking about this particular use case in the document, let me say I clearly got feedback that: from the 3GPP point of view only UE and UPF are the slice endpoints and all the nodes in between RAN, PE nodes etc., are slice realization endpoints. So we are a bit off here w.r.t terminology for this use case and this would be indicated as such in the update to be made https://tools.ietf.org/html/draft-clt-dmm-tn-aware-mobility-08 . So my sincere suggestion would be to use terms neutral as you agreed on the other thread.* > > > I guess, we ought to be cognizant when we tag 'IETF' for some of > > these definitions. > > > > The above also mentions 4G/5G Core nodes aka SGW/PGW/all-variants-of-UPFs= and > > these are again not typically 'IETF Network Slice Endpoints'. > > [Reza] As mentioned above the 'IETF Network Slice and 'IETF Network Slic= e Endpoint are technology-agnostics. In draft these nodes are are called DA= N (Device, Application, NF) > > which shows its true technology-agnostics. > > *[Uma]: Agree and that aspect clearly specified in the document. * > > > Could you please give your thoughts here? > > [Reza] > > > > 2. > > > > Section 1 says > > > > "IETF network slices are created and managed within the scope of one > > or more network technologies (e.g., IP, MPLS, optical). : > > > > > > Obviously, optical is a bigger topic and if we talk about optical solutio= ns like > > OTN (Layer 1) and SPN (Layer 1.5) are more controlled by other SDOs. SPN= has > > a complete slicing solution with not much bearing to IETF. > > > > So, could you please expand 'optical' in the list above? Is it the vario= us optical control plane > > specifications done here, you were referring to? > > > > -- > > Uma C. > > > > > > > > --000000000000e5085b05bb2ba077 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Reza,

Many thx for = your reply.

See a quick response in-line.

--
Uma C.

On Fri, Feb 12, 2021 at 6:46 AM R= okui, Reza (Nokia - CA/Ottawa) <= reza.rokui@nokia.com> wrote:

Hi= Uma,

Th= e comments are inlined.

=C2=A0

Re= za

=C2=A0

=C2=A0

=C2=A0

From: = Teas <teas-bounces@ietf.org>= ; on behalf of Uma Chunduri <umac.ietf@gmail.com>
Date: Thursday, February 11, 2021 at 7:26 PM
To: TEAS WG <t= eas@ietf.org>
Cc: dmm <dmm@ie= tf.org>
Subject: [Teas] draft-ietf-teas-ietf-network-slice-definition-00<= /u>

=C2=A0

Dear All,

=C2=A0

2 questions on this draft:

=C2=A0

1.=C2=A0

Section 4.2 defines 'IETF Network Slice endpoint= s'

=C2=A0

It Says -

=C2=A0

" o = They are conceptual points of connection of a consumer network,

=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 network function, device, or application to the IETF net=
work
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 slice.=C2=
=A0 This might include routers, switches, firewalls, WAN,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 4G/5G RAN n=
odes, 4G/5G Core nodes, application acceleration, Deep=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Packet Insp=
ection (DPI), server load balancers, NAT44 [RFC3022],
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 NAT64 [RFC6146], HTTP header enrichment functions, an=
d TCP
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 optimizers.=
"
=C2=A0<=
u>
=C2=A0<=
u>
I presume 4G/5=
G RAN nodes, you meant eNB, gNB-DU, gNB-CU-UP etc. If yes,
there was a qu=
estion from one of the 3GPP delegates on how=C2=A0this can be called as =

'IETF Netw=
ork Slice Endpoint'? 
=
=C2=A0
[Reza] Yes 4G/5G RAN nodes means eNB, gNB-DU, gNB-CU-UP etc. How=
ever, the fundamental aspect to be considered for IETF Network Slice is tha=
t it is technology-agonistic.
Note that also that RAN nodes for example have two logical compo=
nents; Radio components and transport component. The IETF Network Slice add=
resses the connectivity from Transport component of RAN=C2=A0=

 (which in=
 today=E2=80=99s technology it is the data-path) to other endpoints. It is =
called 'IETF Network Slice Endpoint' because user=E2=80=99s traffic=
 starts from this entry point.
<= div>=C2=A0[Uma]: Indeed and=C2=A0 in all these cases i.e., between DU-CU= , gNB-UPF or eNB-SGW, SGW-PGW, UPF-UPF the packet emitted would be UDP/IP p= acket encapsulating the user payload with the overlay header. But just beca= use it is emitting the IP packet we might not want to rename these as=C2=A0= 'IETF=C2=A0 Network Slice Endpoint'.=C2=A0 As we are speaking abou= t this particular use case in the document, let me say I clearly got feedba= ck that: from the 3GPP point of view only UE and UPF are the slice endpoint= s and all the nodes in between RAN, PE nodes=C2=A0 etc., are slice realizat= ion endpoints. So we are a bit off here w.r.t terminology for this use case= and this would be indicated as such in the update to be made=C2=A0 https:/= /tools.ietf.org/html/draft-clt-dmm-tn-aware-mobility-08. So my sincere = suggestion would be to use terms neutral as you agreed on the other thread.= 
=C2=A0
I guess, we ou=
ght to be cognizant when we tag 'IETF' for some of 
these definiti=
ons. 
=C2=A0<=
u>
The above also=
 mentions 4G/5G Core nodes aka SGW/PGW/all-variants-of-UPFs and <=
/u>
these are agai=
n not typically 'IETF Network Slice Endpoints'.
[Reza] As mentioned above the 'I=
ETF Network Slice=C2=A0 and 'IETF Network Slice Endpoint are technology=
-agnostics. In draft these nodes are are called DAN (Device, Application, N=
F) =C2=A0
which shows its true technology-agnostics=
.
[Uma]: Agree and that = aspect clearly specified in the document.=C2=A0
= 
=C2=A0
Could you please give your thoughts here?<=
u>
[Reza]
=C2=A0<=
u>
2. <=
/u>
=C2=A0<=
u>
Section 1 says=

=C2=A0<=
u>
"IETF net=
work slices are created and managed within the scope of one
=C2=A0=C2=A0 o=
r more network technologies (e.g., IP, MPLS, optical). :
=C2=A0<=
u>
=C2=A0<=
u>
Obviously, opt=
ical is a bigger topic and if we talk about optical solutions like <=
u>
OTN (Layer 1)=
=C2=A0 and SPN (Layer 1.5) are more controlled by other SDOs. SPN has 
a complete sli=
cing solution with not much bearing to IETF. 
=C2=A0<=
u>
So, could you =
please expand 'optical' in the list above? Is it the=C2=A0 various =
optical control plane 
specifications=
 done here, you were referring to? 
=C2=A0<=
u>
--
Uma C.<=
u>
=C2=A0<=
u>
=C2=A0<=
u>
=C2=A0<=
u>
--000000000000e5085b05bb2ba077-- From nobody Fri Feb 12 16:38:18 2021 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A33C03A1231; Fri, 12 Feb 2021 16:33:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: dmm@ietf.org, ek.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161317641365.31337.12834605668406683672@ietfa.amsl.com> Date: Fri, 12 Feb 2021 16:33:33 -0800 Archived-At: Subject: [DMM] dmm - Requested session has been scheduled for IETF 110 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 00:33:43 -0000 Dear Sri Gundavelli, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dmm Session 1 (2:00 requested) Monday, 8 March 2021, Session III 1700-1900 Room Name: Room 4 size: 504 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/110/sessions/dmm.ics Request Information: --------------------------------------------------------- Working Group Name: Distributed Mobility Management Area Name: Internet Area Session Requester: Sri Gundavelli Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 25 Conflicts to Avoid: People who must be present: Dapeng Liu Erik Kline Satoru Matsushima Sri Gundavelli Resources Requested: Special Requests: Preferred days: Monday or Tuesday --------------------------------------------------------- From nobody Fri Feb 12 17:19:33 2021 Return-Path: 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 CE5E03A1168 for ; Fri, 12 Feb 2021 17:19:31 -0800 (PST) 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 mQlnp84BOMDZ for ; Fri, 12 Feb 2021 17:19:29 -0800 (PST) Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) (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 C53793A0EFA for ; Fri, 12 Feb 2021 17:19:29 -0800 (PST) Received: by mail-yb1-xb2f.google.com with SMTP id d184so1309627ybf.1 for ; Fri, 12 Feb 2021 17:19:29 -0800 (PST) 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; bh=6JDC6hERfJefiygJj+GkUsYdrnsUilFaqBvpokTRjK0=; b=kh16yohqIJ9ohrXWbUjFvR0vWzLITpJP73uTxT47re8V07efnNZjHw4EtkqhMRRKCx zrnWuszqvdgTxE8K/Km+kSm80FeNsne/0iDxaHXT7n69v9S8+lmBdQev/2/HLIdz43da cWFe2AQkiOvFMfxudlDklM/GWo//nqnyYI0FAwOCKyi6gwwnOsKM4c/hFF23LpaiGgvu EMt0aN6MSdAAcrWXnXW9WFNXqNecbKK+fIFy82v79mJD7VyOm0ON5SQI9GFiFD+DhRn+ x6yrPznDj0RmKwRV09YKKHmdWs4uVlp/i2El+v8vPpVSfsrCRu3RLIGbTxAB/OgymWgJ rJVg== 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; bh=6JDC6hERfJefiygJj+GkUsYdrnsUilFaqBvpokTRjK0=; b=eyAj0+2Wd/c+8Esut//KNnF6h1wGpO9sx3Y0603+xZ0lmwIgx+PFOiTJidr11BLQU9 bS1W2FH0yR84NNQ3lLlccwg04R/nB1zbpjWIhFy+5xYHo1Bsc2vWOgzJJBQYf0AaGLr1 2vG50HF+NLCj1ZhGZP/H9J0NRPLQ7TLj74Ju79IYcx10L0n8Ea5+YMMux9EZ/iyEHnIR wIqbHq4hhmEgo4ByJJL3vNcfBqmXrDgtbjA9nfRczQfeHFLrMecV/ytWSm13zgeM160e 72fecn2sUIvVasqjy6kK28j/TZc/tTV3ttMtRra4qFIOlEfvwn7/UQa8uv5YPtReg0JB BgMg== X-Gm-Message-State: AOAM531cZri0FF4JpDBizeRZKS3KVAHElxv9lFXMvGPHg5HkdONpP5Z0 xnq0iSbU7k+yCEv/ReJHvq1cp/Xlf7SIltU5qlve1bjL X-Google-Smtp-Source: ABdhPJyBk2XcZFUz7HNRq/chh71dTAieKkfLipFLAxRByxh91OtSbrLkXoWeddfAs3cea/pRGnEUSdP2af/EuItosDU= X-Received: by 2002:a25:3055:: with SMTP id w82mr7718715ybw.142.1613179168969; Fri, 12 Feb 2021 17:19:28 -0800 (PST) MIME-Version: 1.0 References: <161317847377.28517.1721333635804322519@ietfa.amsl.com> In-Reply-To: <161317847377.28517.1721333635804322519@ietfa.amsl.com> From: Uma Chunduri Date: Fri, 12 Feb 2021 17:19:18 -0800 Message-ID: To: dmm Content-Type: multipart/alternative; boundary="0000000000005354c205bb2d8b65" Archived-At: Subject: [DMM] Fwd: New Version Notification for draft-clt-dmm-tn-aware-mobility-09.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 01:19:32 -0000 --0000000000005354c205bb2d8b65 Content-Type: text/plain; charset="UTF-8" Dear All, This update covers the comments received related to TEAS work reference (in the list and off the list). Please review & comment and we will continue to improve this further (with other TBDs, after the adoption call concludes). -- Uma C. (on behalf of all co-authors). ---------- Forwarded message --------- From: Date: Fri, Feb 12, 2021 at 5:07 PM Subject: New Version Notification for draft-clt-dmm-tn-aware-mobility-09.txt To: Luis M. Contreras , Jeff Tantsura , John Kaippallimalil < john.kaippallimalil@futurewei.com>, Praveen Muley , Richard Li , Sridhar Bhaskaran < sridharb@altiostar.com>, Uma Chunduri A new version of I-D, draft-clt-dmm-tn-aware-mobility-09.txt has been successfully submitted by Uma Chunduri and posted to the IETF repository. Name: draft-clt-dmm-tn-aware-mobility Revision: 09 Title: Transport Network aware Mobility for 5G Document date: 2021-02-12 Group: Individual Submission Pages: 24 URL: https://www.ietf.org/archive/id/draft-clt-dmm-tn-aware-mobility-09.txt Status: https://datatracker.ietf.org/doc/draft-clt-dmm-tn-aware-mobility/ Htmlized: https://datatracker.ietf.org/doc/html/draft-clt-dmm-tn-aware-mobility Htmlized: https://tools.ietf.org/html/draft-clt-dmm-tn-aware-mobility-09 Diff: https://www.ietf.org/rfcdiff?url2=draft-clt-dmm-tn-aware-mobility-09 Abstract: This document specifies a framework and mapping from slices in 5G mobile systems to transport slices in IP, Layer 2 and Layer 1 transport networks. Slices in 5G systems are characterized by latency bounds, reservation guarantees, jitter, data rates, availability, mobility speed, usage density, criticality and priority. These characteristics should be mapped to the transport network slice characteristics that include bandwidth, latency and criteria such as isolation, directionality and disjoint routes. Mobile slice criteria need to be mapped to the appropriate transport slice and capabilities offered in backhaul, midhaul and fronthaul connectivity segments between radio side network functions and user plane function(gateway). This document describes how mobile network functions map its slice criteria to identifiers in IP and Layer 2 packets that transport network segments use to grant transport layer services during UE mobility scenarios. Applicability of this framework and underlying transport networks, which can enable different slice properties are also discussed. This is based on mapping between mobile and transport underlays (L2, Segment Routing, IPv6, MPLS and IPv4). Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --0000000000005354c205bb2d8b65 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,

This update covers the commen= ts received related to TEAS work reference=C2=A0(in the list and off the li= st).

Please review & comment and we will conti= nue to improve this further (with other TBDs, after the adoption call concl= udes).

--
Uma C. (on behalf of all co-au= thors).

---------- Forwarded message ---------
From: <internet-drafts@ietf.or= g>
Date: Fri, Feb 12, 2021 at 5:07 PM
Subject: New Vers= ion Notification for draft-clt-dmm-tn-aware-mobility-09.txt
To: Luis M. = Contreras <luismiguel.contrerasmurillo@telefonica.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Joh= n Kaippallimalil <j= ohn.kaippallimalil@futurewei.com>, Praveen Muley <praveen.muley@nokia.com>, Richard Li <= ;richard.li@futurewei.com&g= t;, Sridhar Bhaskaran <sridhar= b@altiostar.com>, Uma Chunduri <umac.ietf@gmail.com>



A new version of I-D, draft-clt-dmm-tn-aware-mobility-09.txt
has been successfully submitted by Uma Chunduri and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-clt-dmm-tn-aware-mobili= ty
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A009
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Transport Network aware Mobility f= or 5G
Document date:=C2=A0 2021-02-12
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 24
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/archive/id/draft-clt-dmm-tn-aware-mobi= lity-09.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-clt-dmm-tn-aware-mobility/=
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-clt-dmm-tn-aware-mobility<= /a>
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://tools.ietf.org/html/draft-clt-dmm-tn-aware-mobility-09
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-clt-dmm-tn-aware-= mobility-09

Abstract:
=C2=A0 =C2=A0This document specifies a framework and mapping from slices in= 5G
=C2=A0 =C2=A0mobile systems to transport slices in IP, Layer 2 and Layer 1<= br> =C2=A0 =C2=A0transport networks.=C2=A0 Slices in 5G systems are characteriz= ed by
=C2=A0 =C2=A0latency bounds, reservation guarantees, jitter, data rates, =C2=A0 =C2=A0availability, mobility speed, usage density, criticality and =C2=A0 =C2=A0priority.=C2=A0 These characteristics should be mapped to the = transport
=C2=A0 =C2=A0network slice characteristics that include bandwidth, latency = and
=C2=A0 =C2=A0criteria such as isolation, directionality and disjoint routes= .
=C2=A0 =C2=A0Mobile slice criteria need to be mapped to the appropriate tra= nsport
=C2=A0 =C2=A0slice and capabilities offered in backhaul, midhaul and fronth= aul
=C2=A0 =C2=A0connectivity segments between radio side network functions and= user
=C2=A0 =C2=A0plane function(gateway).

=C2=A0 =C2=A0This document describes how mobile network functions map its s= lice
=C2=A0 =C2=A0criteria to identifiers in IP and Layer 2 packets that transpo= rt
=C2=A0 =C2=A0network segments use to grant transport layer services during = UE
=C2=A0 =C2=A0mobility scenarios.=C2=A0 Applicability of this framework and = underlying
=C2=A0 =C2=A0transport networks, which can enable different slice propertie= s are
=C2=A0 =C2=A0also discussed.=C2=A0 This is based on mapping between mobile = and
=C2=A0 =C2=A0transport underlays (L2, Segment Routing, IPv6, MPLS and IPv4)= .





Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--0000000000005354c205bb2d8b65-- From nobody Fri Feb 19 03:01:23 2021 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 893AF3A13F0; Fri, 19 Feb 2021 03:01:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.26.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmm@ietf.org Message-ID: <161373247250.31354.5426190163936331639@ietfa.amsl.com> Date: Fri, 19 Feb 2021 03:01:12 -0800 Archived-At: Subject: [DMM] I-D Action: draft-ietf-dmm-srv6-mobile-uplane-10.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2021 11:01:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Mobility Management WG of the IETF. Title : Segment Routing IPv6 for Mobile User Plane Authors : Satoru Matsushima Clarence Filsfils Miya Kohno Pablo Camarillo Garvia Daniel Voyer Charles E. Perkins Filename : draft-ietf-dmm-srv6-mobile-uplane-10.txt Pages : 32 Date : 2021-02-19 Abstract: This document shows the applicability of SRv6 (Segment Routing IPv6) to the user-plane of mobile networks. The network programming nature of SRv6 accomplish mobile user-plane functions in a simple manner. The statelessness of SRv6 and its ability to control both service layer path and underlying transport can be beneficial to the mobile user-plane, providing flexibility, end-to-end network slicing and SLA control for various applications. This document describes the SRv6 mobile user plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-srv6-mobile-uplane/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-10 https://datatracker.ietf.org/doc/html/draft-ietf-dmm-srv6-mobile-uplane-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-srv6-mobile-uplane-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 19 03:13:27 2021 Return-Path: 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 B89B33A003F for ; Fri, 19 Feb 2021 03:13:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=CHMeGVre; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Kyt8lNgn 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 JsnKLc5ZQJp7 for ; Fri, 19 Feb 2021 03:13:23 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C77DC3A003E for ; Fri, 19 Feb 2021 03:13:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2566; q=dns/txt; s=iport; t=1613733202; x=1614942802; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=5TLciz7yLawwEoId1chUpZDzdB0rFuySbZnx5/fuBdo=; b=CHMeGVred25nTNx8I9kOiAtpdwsmJ33+t8spaBfd0h2Np2SUbXtD3rCn XjQzkVTRbvL02kwbqNhH1jrn7PlU4LZIOpRpVpiiVqsSr7bveEZh9Le6S 9hNyJveJtIqzFHhy4Em8zuuzHTr3po2Wkn93yV/L3Icp9g8xtHu5JLj39 o=; IronPort-PHdr: =?us-ascii?q?9a23=3AdyuIoxxfGWTL7sHXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5ZRWFt/RgkFGPWp/UuLpIiOvT5qbnX2FIoZOMq2sLf5EEUR?= =?us-ascii?q?gZwd4XkAotDI/gawX7IffmYjZ8EJFEU1lorHC2LUYTH9zxNBXep3So5msUHR?= =?us-ascii?q?PyfQN+OuXyHNvUiMK6n+C/8pHeeUNGnj24NLhzNx6x6w7Ws5ob?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CEEgBFnC9g/5pdJa1iHQI9BQUECRa?= =?us-ascii?q?BUYFRUQd2WjYxCgGHfgOOCgOZHoJTA1QLAQEBDQEBBQIWDQgCBAEBhE0Cggw?= =?us-ascii?q?CJTgTAgMBAQsBAQUBAQECAQYEcYVhAQyGRAEBAQQBATgGAQEsDAsEAgEIEQQ?= =?us-ascii?q?BAR8QJwsdCAIEEwiCZIJVAy4BAwujfAKKJXSBNIMEAQEGgTcCDkGDHhiCEgm?= =?us-ascii?q?BOAGCdYZYg3MmHIFBQYFUglc+gl0BAQIBARWBSINIgiuBT4FfBFECFEcWJ3o?= =?us-ascii?q?zL5AiqQMKgnuJO5J3gzGBNIkYkniCSZRGizKWVQICAgIEBQIOAQEGgWsjgVd?= =?us-ascii?q?wFRohgmkJRxcCDZIOhRSFRXM3AgYKAQEDCXyKCAGBDgEB?= X-IronPort-AV: E=Sophos;i="5.81,189,1610409600"; d="scan'208";a="865667670" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Feb 2021 11:13:21 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 11JBDLrL030068 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 19 Feb 2021 11:13:21 GMT Received: from xfe-aln-004.cisco.com (173.37.135.124) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 19 Feb 2021 05:13:15 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xfe-aln-004.cisco.com (173.37.135.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Fri, 19 Feb 2021 05:13:15 -0600 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 19 Feb 2021 06:13:14 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SVQFq7r14hN4hUC9cNmIxCmVeEep2/dygZ5cI6p+J/FvRFSBVR+PDKHfDkFfX5HLfJLlllqyFoXveBdRKEMVaQuWgcQZEAGAIeH0eOReJcFTz8+GMWYwyMlfZDbLRsymRILv4OUlQHNMPnaGye/sRxOgXZibTOoEcKanL9/NlhJ0GWoHpNcWqWVDZ8c2FjeTaig0RrnA7GbfE0+2JJOogyhT5r9jH6Gmj7KAli2znaMx4Mg5l+UUzEdZm4vWqpDhTbgQPUIBlWETNN5ZP6IXNRn6frFNdAsPzM0qMys/M34eK/zNIgf8Hzb+pnw33TWfHxKEpslOvLaRDzAmWzfKbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=r4hw6WKwuo66WQfl6aqVrm93DY2AK9JOCftGbGVJdXg=; b=ixYSuoi3sFMBgoO5qakCqhIIg1WTaWol566fYMihOI4ogqom2FEVcipQUmvyGUPxQRuLNnAQg/P2GM4OoqGQLo3SE7HSntZM3lxcOLVuNTRgjdli7IBKHWq2X2xiLZrZ1Ke/3YQOAnaYZcjfo0qD02m46pUtM2+Rff3i+QAmSsk268rk+R55YELqcYkYXR/mTDvZv3vNIYM8JkRkm+UMuil2Y9R9ppLn3dF8+sFsic/EdofdAI54hvMf8RLa2hG/gizNKJQtlO+mBmET3z6xJMFlfTyyeZuF54VeUSNtgI7EZTWwieZDNbK8Opllwve90l5LqfPJ+eAn4ua3oEcqeQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=r4hw6WKwuo66WQfl6aqVrm93DY2AK9JOCftGbGVJdXg=; b=Kyt8lNgnILOrIyEGY+FNU1JISQYsyXcjRN5EfP3pPb3FEic5Q6n7G4ai9rs4wgJ8r90kUbyKdSdookjKPd+afBkSok3ENBxnXI7yaeDgxN71xOwlJXqwL1InD9N/z5g7bwKZphAlDy8hKkQe1rk/y9ckWJQkwQPjdlFMfYrwngE= Received: from SA2PR11MB5082.namprd11.prod.outlook.com (2603:10b6:806:115::5) by SN6PR11MB3376.namprd11.prod.outlook.com (2603:10b6:805:c7::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.27; Fri, 19 Feb 2021 11:13:13 +0000 Received: from SA2PR11MB5082.namprd11.prod.outlook.com ([fe80::4011:122:c4d3:516e]) by SA2PR11MB5082.namprd11.prod.outlook.com ([fe80::4011:122:c4d3:516e%7]) with mapi id 15.20.3846.043; Fri, 19 Feb 2021 11:13:13 +0000 From: "Pablo Camarillo (pcamaril)" To: "dmm@ietf.org" Thread-Topic: [DMM] I-D Action: draft-ietf-dmm-srv6-mobile-uplane-10.txt Thread-Index: AQHXBq6zNG9kKfqnwUK1Rz0psllbfapfUkRA Date: Fri, 19 Feb 2021 11:13:13 +0000 Message-ID: References: <161373247250.31354.5426190163936331639@ietfa.amsl.com> In-Reply-To: <161373247250.31354.5426190163936331639@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [88.24.27.24] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3ae79647-b062-45fc-4221-08d8d4c7595c x-ms-traffictypediagnostic: SN6PR11MB3376: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: d9h+7xyXTXwuISYOPh/X0Jhk2IVG+SmZfTyUfyey5cvUqeixOaSrDlYD1WhIAYf6/gMtpp1wM7EmZfckDU9MRKxbfZ53JdtPUF9dClmyvIzu4Bj1+p2binWFqzUIQPieejBPrLSxqR8qFTmb1xjieAqSyNgDdjhUT/iOr5hSm/WPvDdBIwV0Vyev8o1UFCWJCIIi1tsdV+V8als//3mAISrfF8rD3o3JAzXSdEaxCkz1qGAFUwVwUMii/h+U/52m/vhWCnPvGdtvnHRisYer+ZWW3EpMjKzHw1odvcvhM5lSLboFwDEdg0pYhWRBVfJLva4bQVm0qadkAhSFC0ToVYpB10P3UncV1LTRuAFwBHG2wknhAQCrsc00o65BOUCKrvATDQxJdk9RYZnMoXGquK6/YYo1LyCOXkFGwt/eb43UHQMzJnLGG01WEKkhzznMizPf7JS7FIwgsNZjNEk5fQxvRmlAywkSHUogefJRsuZDPEufYEwYL5GMp4wAZKQG2/fnJjREz6iwq79w77MhF+UXB3mOEN4F6miT/wmChmHUZi/sJilmBUVQESBaf2ujuiJrcJZ/8sqMuQGaC21blaWsysG9FyhD165rcs9Cpqo= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA2PR11MB5082.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(346002)(136003)(366004)(39860400002)(396003)(66574015)(83380400001)(186003)(7696005)(33656002)(6916009)(966005)(76116006)(5660300002)(8936002)(8676002)(53546011)(6506007)(55016002)(2906002)(52536014)(66446008)(9686003)(478600001)(316002)(66556008)(86362001)(71200400001)(66946007)(66476007)(64756008)(26005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?840B9K2l3GH3aL75leISoyZqzv8VLBbbrESPyEVQHwsqr5+sEPriJRJFzvqL?= =?us-ascii?Q?cHXYRLGIml4wPoc874x6m61u7uNWQS7qwKrhPmyMdR9MBJBsELNdc4bP5Mgs?= =?us-ascii?Q?+6vkjo3L+C7ZmUU5M12QoAqtnvHN+wTBcDXFv85YbUkM90GSePrbbih5P2Rk?= =?us-ascii?Q?yp2L1aYFmCuwhSnQxrk4F65iRnsQLUaztv0rmJr7Tm5hFuQTbwhVrPMN2Kkz?= =?us-ascii?Q?xXTuZTH519dOdgQCPM1CMgdaN7FiKwMR2xu+sw68bCxPlX8PUDtOEFauos0Y?= =?us-ascii?Q?1dgM5eeKfz68RT7Qf1sNNSYIGUDBtMo3Gv8+GtpWovusOlb0lhNmblUbzlPs?= =?us-ascii?Q?byoAkmH0mtfnhEOhsDbOKShDG49uoKESP8qM/q9V6LPD8HplHYaSDbIl6ri4?= =?us-ascii?Q?Cws/RdbqRDL2WxWEQqhlaJvNYI8WIr+/LbdBsnCiLMBEzxchI0b5hZieogNx?= =?us-ascii?Q?tvzGxFm4zeOCs2f3FcmD3vPsAHjraTM0N3IO0DE1TlAvmCLnoGE+QU38keZq?= =?us-ascii?Q?vAjUJSKRlUykxmtiljhqVIIOFsFmEKPQ9GUJKdPsNPOtF8XY9XN1HasF02Qq?= =?us-ascii?Q?GgSDdwKouC6DrPCOr4dEHjLjkHyC56gMLYKptC3taFT2xAZyuTzXf+SIRHk6?= =?us-ascii?Q?iGzt8h0MT+Zx1EwHRJ0kRHrKYhHAUyLjlQMNKR7n/HgPyddFDTppMzY+En2V?= =?us-ascii?Q?1yCm7gK6ntq+cd38B3eSCWGtvFaQ7+MU5izOMECiYESZvdCYf4x+Q6XR7KZh?= =?us-ascii?Q?yc/1UnNpAVakrndnXih3dRNf7PWQC+5wh6C7A3bLzaoG9xg8YTQwNOyAmsIr?= =?us-ascii?Q?nCOrQfXcS+T+OVJLjvnSrwk1a52NMxXByQur09tKl1SEhmg5Ec54SvX3WVV6?= =?us-ascii?Q?GOW9S+zEpnu90LHhTdCm63r/oaHu/7I3QmrDlVcuoJrm90m7/arpZOP5Ly3t?= =?us-ascii?Q?DmBmMBZhfXSixuqaBPUbjtultiLAu0NBxNoyvXyJJWc4Xrfqa+2AzR4eLNzh?= =?us-ascii?Q?YbbaK4uFKca7fHbqDmmuIXqmMZebgKKRJMRk7Gyy7RtEiwomq/j3D2vOU0cj?= =?us-ascii?Q?c4Z/slcBb2l8c4LNbIBY37YVgz418uDZ+GchdRXrUOHYPXKC6rnBR6kz2AgA?= =?us-ascii?Q?/JHRowB2pyRZZ+G9EGeWNQE5tdgPbNdwNwaJorkXWId4JELo6DL4N/ZMqRNH?= =?us-ascii?Q?spl6/euksp/qGRuq7RpcFX9Ns2HeL+ZFAsZE527MJuoIA8STEXEc2MCWYVZz?= =?us-ascii?Q?NVa4+MFaklEYdwrVsL6+8WYin5qCcNyRoMx4CYr9Re6TqvwK+ZY/WWnm7H78?= =?us-ascii?Q?mhc=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA2PR11MB5082.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3ae79647-b062-45fc-4221-08d8d4c7595c X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2021 11:13:13.4927 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: PrsYS+m7IfR6lP0RCD22uc+Yo/I35wqVpau4skOZ+3dVY2oEjCYNCk6wfq50KXf/ez51LqcN9nKZSYSPeQ6Lsg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB3376 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [DMM] I-D Action: draft-ietf-dmm-srv6-mobile-uplane-10.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2021 11:13:25 -0000 Hi all, We have posted a new revision of draft-ietf-dmm-srv6-mobile-uplane. We have fixed several typos throughout the document and we have updated the= SRv6 Endpoint Behavior pseudocodes to reuse the same format as in RFC8754 = and net-pgm. Please review and let us know your feedback. Thanks, Pablo. -----Original Message----- From: dmm On Behalf Of internet-drafts@ietf.org Sent: viernes, 19 de febrero de 2021 12:01 To: i-d-announce@ietf.org Cc: dmm@ietf.org Subject: [DMM] I-D Action: draft-ietf-dmm-srv6-mobile-uplane-10.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Distributed Mobility Management WG of the = IETF. Title : Segment Routing IPv6 for Mobile User Plane Authors : Satoru Matsushima Clarence Filsfils Miya Kohno Pablo Camarillo Garvia Daniel Voyer Charles E. Perkins Filename : draft-ietf-dmm-srv6-mobile-uplane-10.txt Pages : 32 Date : 2021-02-19 Abstract: This document shows the applicability of SRv6 (Segment Routing IPv6) to the user-plane of mobile networks. The network programming nature of SRv6 accomplish mobile user-plane functions in a simple manner. The statelessness of SRv6 and its ability to control both service layer path and underlying transport can be beneficial to the mobile user-plane, providing flexibility, end-to-end network slicing and SLA control for various applications. This document describes the SRv6 mobile user plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-srv6-mobile-uplane/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-10 https://datatracker.ietf.org/doc/html/draft-ietf-dmm-srv6-mobile-uplane-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dmm-srv6-mobile-uplane-10 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm From nobody Fri Feb 19 05:25:00 2021 Return-Path: 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 1B2923A0C6C; Fri, 19 Feb 2021 05:24:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 UYqRPVsSGTpA; Fri, 19 Feb 2021 05:24:58 -0800 (PST) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 E8E0E3A0C6A; Fri, 19 Feb 2021 05:24:57 -0800 (PST) Received: by mail-pg1-x52f.google.com with SMTP id t11so4215620pgu.8; Fri, 19 Feb 2021 05:24:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:message-id:date :to:cc; bh=Nug2VT4CMk4iLea4B2106SU8bu5byVY3iqgEUtwhnkc=; b=HLB+7aUP3OVh84CI8tM29LTVzvBK/OuFPK3DlRzYFPz50eZQKrtdJfBlckVoLN+9OR IFTZEP/uPX1WZ0jjAJRUg17tW+uE2tpMJhN1nEQJRyMDxJf1nbbwTl+VO1wbIG7BiNP7 cKfX6Vg80QjvU+0u24zdIyNripka6QHhXKcC/Qvrfh17CMN9vu/g5cFb60evVdvysSt8 Y6RDOMYssAl19gwW5a4iObBozcs4gTcpg7ZG4BydibctRlT3nIr8i4yGQtVOkBz+DyJK +P3n9QKZY6k5ns1PYtPjAln5ITZbdHaZ+ykqf9Ylzi2jRgy0Q8dT0eZ3Kc1k8D8f/CM5 A9Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:message-id:date:to:cc; bh=Nug2VT4CMk4iLea4B2106SU8bu5byVY3iqgEUtwhnkc=; b=jgEf6rsfVXL4/I1UMhIGyFTsjRtGQdaKzEiHeumsG1mid5lN3qiqkwzRRpFy79jiye xIu/GNXRfHbs+BGbHj5HpPrd6alwS4svUieOu2vwg/vYCDjWHlEOWTmgGcY73Oh+lXPj Ed7UIqHXMZn8Lj3KR/8uk4/1ao61fHaRn/rcOnStYFInXivNkKkWGDAmx8fS1xNvQsRA YleeeRHexPAy7u70POJddof5qLoahOqOgf0r/584pbnxxXG3BnllXvpF1rjK37s/e/Ob uqRGdJX70rpAUj9ed2SFHlm5fT1DxQke9w9IJLyoUetKew4YogQ05huw7nn/laJ4cO6Z SlBw== X-Gm-Message-State: AOAM530uD+h3zfKsuUpDrUS/Y6QLCD+Hw/d1eF7CZQYpFSR89Od3lhiN bN8XVrHcTX3IW9Q+pCLUU4Q= X-Google-Smtp-Source: ABdhPJzEMen7IyrnG9jmRc61YaQsYuzsgxeLJ34wFygg9+QgU0y0pfcq0/SiPIUeepDZ5wItOCVHoA== X-Received: by 2002:a63:4082:: with SMTP id n124mr8637865pga.340.1613741097217; Fri, 19 Feb 2021 05:24:57 -0800 (PST) Received: from ?IPv6:2400:2411:8900:0:9921:b620:f6e5:9805? ([2400:2411:8900:0:9921:b620:f6e5:9805]) by smtp.gmail.com with ESMTPSA id c18sm9687890pfi.167.2021.02.19.05.24.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 19 Feb 2021 05:24:56 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Satoru Matsushima Mime-Version: 1.0 (1.0) Message-Id: <41D23C74-6501-4FF8-BC34-F4B46E79DE5B@gmail.com> Date: Fri, 19 Feb 2021 22:24:54 +0900 To: dmm@ietf.org Cc: dmm-chairs@ietf.org, ek.ietf@gmail.com, sgundave@cisco.com X-Mailer: iPad Mail (18D52) Archived-At: Subject: [DMM] Call for Agenda: IETF110 DMM X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2021 13:24:59 -0000 Folks, DMM meeting in IETF110 online will be held at March 8th 1600-1800 UTC. If you have any topic for the IETF110 DMM meeting, please send the chairs yo= ur topic with the title and the presenter. Cheers, --satoru > On Jan 22, 2021, at 11:07, IETF Meeting Session Request Tool wrote: >=20 > =EF=BB=BF >=20 > A new meeting session request has just been submitted by Sri Gundavelli, a= Chair of the dmm working group. >=20 >=20 > --------------------------------------------------------- > Working Group Name: Distributed Mobility Management > Area Name: Internet Area > Session Requester: Sri Gundavelli >=20 >=20 > Number of Sessions: 1 > Length of Session(s): 2 Hours > Number of Attendees: 25 > Conflicts to Avoid:=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > People who must be present: > Sri Gundavelli > Erik Kline > Dapeng Liu > Satoru Matsushima >=20 > Resources Requested: >=20 > Special Requests: > Preferred days: Monday or Tuesday > ---------------------------------------------------------