[DMM] review comment to SRv6-mobile-uplane draft

"Flinck, Hannu (Nokia - FI/Espoo)" <hannu.flinck@nokia-bell-labs.com> Tue, 22 January 2019 12:49 UTC

Return-Path: <hannu.flinck@nokia-bell-labs.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFFB7130F53 for <dmm@ietfa.amsl.com>; Tue, 22 Jan 2019 04:49:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.453
X-Spam-Level:
X-Spam-Status: No, score=-6.453 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 SrkNa9CANfzp for <dmm@ietfa.amsl.com>; Tue, 22 Jan 2019 04:49:38 -0800 (PST)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10136.outbound.protection.outlook.com [40.107.1.136]) (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 2353F130F3E for <dmm@ietf.org>; Tue, 22 Jan 2019 04:49:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector2-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pSo+fAnXXjQ1gGgdXXmHLQQJ2Dba1kyOQnPTflDfo4A=; b=jmfCntehKICeUkE8UmblCaE5uaacyLbnhV289U6NXnT2stCsI9NUwq+XEa8eiqdfZRQE12Ix4vBe9DOpWtoiGwkRAXQ0tTOx6zq1fkHo2AFRImbpvftLxXlr8k6bUCq2+BYYRuwEr7prPMalsCMmzU/KPmBif4LBHk0m82NfB6I=
Received: from HE1PR07MB3306.eurprd07.prod.outlook.com (10.170.246.141) by HE1PR07MB3148.eurprd07.prod.outlook.com (10.170.245.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.15; Tue, 22 Jan 2019 12:49:35 +0000
Received: from HE1PR07MB3306.eurprd07.prod.outlook.com ([fe80::4827:8d8b:4c0d:22c9]) by HE1PR07MB3306.eurprd07.prod.outlook.com ([fe80::4827:8d8b:4c0d:22c9%5]) with mapi id 15.20.1558.016; Tue, 22 Jan 2019 12:49:35 +0000
From: "Flinck, Hannu (Nokia - FI/Espoo)" <hannu.flinck@nokia-bell-labs.com>
To: "dmm@ietf.org" <dmm@ietf.org>
Thread-Topic: review comment to SRv6-mobile-uplane draft
Thread-Index: AdSyUE7p1pLKTPaJQhWXMiOZJz8rlw==
Date: Tue, 22 Jan 2019 12:49:35 +0000
Message-ID: <HE1PR07MB3306BB13D261A656D0A553109B980@HE1PR07MB3306.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=hannu.flinck@nokia-bell-labs.com;
x-originating-ip: [131.228.2.16]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; HE1PR07MB3148; 6:BE0vqdUqGVN4JJ/quv2alS6L9UqNO3uvqEL3B/x8u4iIQdG5e9+hJZH6NhYfGeveyppQRCkcJw/segKi/GgFxVaQV5+SC1WtDJm9upSbk5CY9y2kgm/m3n/Rf8BFVCyWWEQqqv2bfwSOSth9Dy7YJ+qogrsp8mBFDA0YQIpObdto1KmwcDb1tl2EWJ6PGco2CKnqdT5D7fIsLvex+u4LynxEtJAoV//HT6wACUl/7FeOdaO1Z+4L03JdPrSpAxGCZfUulACGIUgVlEpm2E3fM1IQRm0tgOMuQMDUWCZgD41jz2SNsSCLajlHatrEwMRXHm17eUoFpo8KYEJM/hNkSFGc7rObgu+3VF06y+bcBieNf7ZaI3JZdgveYt5tEMH0Ez67v3QyFvqFdd5FqVN3r7v8Fo2rbAuyXqUmWMTUaN2vDqjlfdDimngGm4Z9ytldtiDl7uAlCDUEjoYdGz2jyQ==; 5:ooARM+ZPUoJTg18W/2ySQyl7YGfwZPO69Mltlo0tmBPNnX9oZdrCFyUqLdArZRSl/yN8c15Ti7pPDxLbIgh6L7qZnbUlFTG8Ku72i7DrmCvJsR3gP6LY4F5k7hu9Rpo17raWIx/m/H9ApEvQg2khj953ZxMmlhXvL17eD1oiLTbCfT9/rKIWrSZrXBM+WlCMVHwJ7ZsJ23bPEA2Z5Tlq8Q==; 7:5XpootCl/p9E2SS/g6UmH+3rTGBCHYZ1uy7ShXBcLIDnnTU7pWTFfl0oRi/pKdnfw8Iwwj+7WeYpUByr/k/4j+oiejsZ6P59PTO3egflekR5s3v41adjM98ryMRBak3bc2B579U7j115h8K14IYiuw==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 07d5e001-a745-496d-170c-08d680681004
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4618075)(2017052603328)(7193020); SRVR:HE1PR07MB3148;
x-ms-traffictypediagnostic: HE1PR07MB3148:
x-microsoft-antispam-prvs: <HE1PR07MB31484AE75B66578D7FC407E89B980@HE1PR07MB3148.eurprd07.prod.outlook.com>
x-forefront-prvs: 0925081676
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(39860400002)(376002)(136003)(396003)(53754006)(199004)(189003)(30864003)(966005)(6506007)(7696005)(26005)(102836004)(2351001)(186003)(74316002)(106356001)(1730700003)(3846002)(81156014)(4744004)(68736007)(5640700003)(71200400001)(8936002)(97736004)(478600001)(81166006)(71190400001)(6116002)(25786009)(14454004)(55016002)(86362001)(8676002)(6436002)(33656002)(14444005)(53936002)(6916009)(99286004)(66066001)(9686003)(476003)(2906002)(6306002)(256004)(105586002)(305945005)(486006)(2501003)(7736002)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB3148; H:HE1PR07MB3306.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1;
received-spf: None (protection.outlook.com: nokia-bell-labs.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: rjN1nPNLqV7gub7uakrZdRtB5B4fmqaT/T2n5+opNpIo7FvdMrsd94ch7tZkBGP4J1YXb45zXCAYyxnzowTA68bTbKRPmGSC4RXTZbKGAvl8Sj5qNamKh7OQ2lkEjgIMM07/oTObhL3k+XLtZX0NRxpp5T5vLC86IhjOKDE3anDNnjdacUDhq6K+qpIdtnJA66Wp17xzG76vKIwjhqXINOql3iW++KXdnUoV6y03q1QZf+Kc+MRYf6uRjiqSsaldOwD2+9IwFT5NTle5KbIzwfQ5HF4riGrqdflkVghD0Z/zs1DzN/vjZulURSt4kvRtv1i08M+HJNJ/2Noo8oKdjDJwA49Y9TREAdsHkmwZlciXUyygLPzT6v+RyhB+87A3rXlpRxu210tUyVBFB1dgx0DlzNyJ1UepYx6z+glRWtk=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_HE1PR07MB3306BB13D261A656D0A553109B980HE1PR07MB3306eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia-bell-labs.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 07d5e001-a745-496d-170c-08d680681004
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2019 12:49:35.2150 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3148
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/KFZ8ef4B5oZ-pjUx_MJzVycg8yA>
Subject: [DMM] review comment to SRv6-mobile-uplane draft
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Jan 2019 12:49:41 -0000

Hello all

Here are my promised review comments to SRv6-mobile-uplane draft.

Best regards
Hannu
-------------------------------

Abstract

"This document describes the SRv6 mobile user plane behavior and defines the SID functions for that.
It also provides a mechanism for end-to-end network slicing."

I didn't find any particular mechanism for slicing that is introduced in this document, but instead section 8 that discusses considerations and makes references to other documents. I suggest to remove this statement about slicing in the abstract.


Section 5.1.1 Packet flow - Uplink

How is the 1-to-1 mapping done or replicated as was mentioned in 5.1?
("This 1-for-1 mapping is replicated here to replace GTP encapsulation with the SRv6 encapsulation, while not changing anything else. ")

What is  "a specific table" where the look up is to be done? Does this mean that to support mobile uplane there needs to be an additional look up table?

Section 5.1.2 packet flow - Downlink

In this case you probably need an additional look up table to map the destination address of the UE with address/SID of the gNB.

What is UE session? Can UE have multiple UE sessions (i.e. multi-homing)? How is the mapping to radio bearer done?

Section 5.1.3
You should qualify how much lower the overhead is.

Section 5.2 Enhanced Mode
How much overhead does the use of multiple SIDs introduce? And what is the impact to header compression?

Not sure I understand this sentence:
"Note that the SIDs MAY use the arguments Args.Mob.Session if required by the UPFs."

When it is required to use Args.Mob.Session? Please note that this is the first time you mention Args.Mob.Session and therefore you should introduce it. In section 6.1 it is said that the Args.Mob.Session provides per-session information. When would a SID need this information and what it would be? And shouldn't it be UPF rather than SID that needs this information?


Section 5.2.1 Packet flow - Uplink

Should show here how Args.Mob.Session is used.

"gNB's control plane associates that session from the UE(A) with the IPv6
address B and GTP TEID T.  gNB's control plane does a lookup on B to
find the related SID list <S1, C1, U2::1>."

What is address B? Shouldn't it be address Z? How is TEID used in this case?

Section 5.3.1 Interworking with IPv6 GTP
How does the SRGW learn SID list to a DA? This must be per-session doesn't it?

Section 5.3.1.1 Packet flow  - Uplink
"There is one instance of the End.M.GTP6.D SID per PDU type." How is the PDU type learnt? By use of TEID?

Section 5.3.1.2 Packet flow - Downlink
"When a packet destined to A arrives at the UPF2, the UPF2 performs a lookup in the table associated to A ..."

How is this table populated? By  the mobility signaling?


Section 5.3.1.3 Scalability
TEID is scoped by the gNB and UPF2, same TEID may appear for different gNBs.

How would GTP echo work for these cases?

Section 6.1 Args.Mob.Session

Seems that this is only for 5G networks (because of use of QFI and R).

Can you please elaborate this a bit more: "Since the SRv6 function is likely NOT to be instantiated per PDU session, Args.Mob.Session helps the UPF to perform the functions which require per QFI and/or per PDU Session granularity."

And explain its relationship with the section 7.

Section 6.2 End.MAP

Is the mapping table used at step 1 mobile user plane specific or is it general for any SRv6?
If only for mobile user plane how is this populated?

Section 6.7 End.Limit
"If the j bit length is zero..." or do you mean j bits are zero?

Section 7 SRv6 supported 3GPP PDU session types

End.DT2M and End.DX2 not defined?

----- end of comments ------