Re: [DMM] Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Tue, 15 June 2021 20:16 UTC

Return-Path: <zzhang@juniper.net>
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 0E7C03A3C76; Tue, 15 Jun 2021 13:16:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.797
X-Spam-Level:
X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=juniper.net header.b=sXtXsarh; dkim=pass (1024-bit key) header.d=juniper.net header.b=QIbqpXk0
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 9rdlbugKjxk3; Tue, 15 Jun 2021 13:15:58 -0700 (PDT)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 E85603A3C73; Tue, 15 Jun 2021 13:15:57 -0700 (PDT)
Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 15FK9Vop005438; Tue, 15 Jun 2021 13:15:56 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=EO2Rkj3E1DcBLzvT7Nxluav4AhuV0wZNkzdYn6neSCQ=; b=sXtXsarh2vgVe0FqpiiU/YSomP8itW+QRWc14bpsMvBg1+fWHA2VFlY1BwCdc7BdUxTG yRt6Pp8AKemLV8NLOtRswAml5ZIlO9lf1uYpnHAXW0eJoMxFBRzXq9gLHJ10Yy8G6DEe 7LPGAAP8PPSaVsf/7R//BufSbFWzZR0+fVcXqpBZhKOVO8NHd9Lf31uzOm4fJQbOq6R2 lQijfIFhmoOeyGNcvc/iKTppJcH3g7X13l54KA9xllcANYrkBRvhAqaKgzePqy/GO5ZL 8uJzfmmy99cHnpyuvsAVbbC0yG3SzFJNp1Kpo2o7PexojUpm27k+Pf51oGm/GIb8mudP Gw==
Received: from nam11-dm6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2175.outbound.protection.outlook.com [104.47.57.175]) by mx0a-00273201.pphosted.com with ESMTP id 396rv1hr4t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 15 Jun 2021 13:15:55 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iXZhQMfCHImvx2nEK48uckHkPGGvz0XQEzNVXDjpsxkvo/P9IPlFRgdQlJ8baFZAuaiDiXGiJ1EvfVQ7JAXEG/w8GOo3YUjDLS4u82sT6QxWsfiu8C9TQflFu4gentL0tM2erCASvEA5+LiWSjfi7Di7++EfQou2bVQheNeLq6qapWaerZ9v1qS+Q/pT4Y2M8Moag3ZdVnwsThMce/FROk/GntywARJH9WAIQ1wKgjaGLuQ+xrCibS3yanLg7vJDLIQO0yNMnU1ZQYksVZcoe8N2TmN2te9i2PqVB+vjXew72c1Rh4StRuWemJVpsRToBBR38KI6wIQUF120n7s9Dw==
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=EO2Rkj3E1DcBLzvT7Nxluav4AhuV0wZNkzdYn6neSCQ=; b=HNCwynjAC7ThScBPFrXB9sRSRtBbiCMORJQmzRykk7sJ9ATKIQMcw0lV7Nwb+FVxaOOjVOCuIhToF1CrpzJdyz5USrdHUE7hi4gFC0VXhBqwL4eVjE6xL8nY/zHArMjFU7peE+Lfu+8kW2n4kw9B5HaU/I4YTEC4B4T9sWza4nu1zLHIPUGm3GlTCcrAgBxkejf0W5kIVmhuVaAIbQ8MpR0u+R8kEckBtqIW9N8m7m2amzwYFs4NUhLbujpl0hLX6R0DjHXeIJR3eqcVice8cEUpmf0EFOoam0PJGOgih2GStroZwNzOqgxiESo1o2g/SkEl8nuPUqmI4cRipuMcqQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EO2Rkj3E1DcBLzvT7Nxluav4AhuV0wZNkzdYn6neSCQ=; b=QIbqpXk0icS0ZlmHi7qqBkUU1/B2pNX+l0IrGzXG27dgDoshg4zwkoptCrGyKB17zCWaroCC/xflALcGu+ohbgtwJVbJ+HiHJv3SjF5yBUMNIgx9O3DWW1C+D2pKam+GwuLnIxGyTSxYSer9kRsjO2x6Ub53XX72QjM3Yt2aHNA=
Received: from BL0PR05MB5652.namprd05.prod.outlook.com (2603:10b6:208:6a::19) by MN2PR05MB6909.namprd05.prod.outlook.com (2603:10b6:208:18d::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.10; Tue, 15 Jun 2021 20:15:52 +0000
Received: from BL0PR05MB5652.namprd05.prod.outlook.com ([fe80::65b6:d24e:d018:8d56]) by BL0PR05MB5652.namprd05.prod.outlook.com ([fe80::65b6:d24e:d018:8d56%5]) with mapi id 15.20.4242.016; Tue, 15 Jun 2021 20:15:52 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: "Pablo Camarillo (pcamaril)" <pcamaril=40cisco.com@dmarc.ietf.org>
CC: "dmm@ietf.org" <dmm@ietf.org>
Thread-Topic: Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13
Thread-Index: AddW+2M8CJHnTSCNT5ee7IcEpVXTXQACM4mAAJ5EtbABIaIDgADMoK6wAB2j57AAG8IdgA==
Date: Tue, 15 Jun 2021 20:15:52 +0000
Message-ID: <BL0PR05MB5652D7E3048F74C8C7F5A8A1D4309@BL0PR05MB5652.namprd05.prod.outlook.com>
References: <BL0PR05MB565295B44940D46F4EFF7C1FD43E9@BL0PR05MB5652.namprd05.prod.outlook.com> <SA2PR11MB5082A858F3E13FE81BD129DBC93B9@SA2PR11MB5082.namprd11.prod.outlook.com> <BL0PR05MB5652E7C02063E3C43225540CD4389@BL0PR05MB5652.namprd05.prod.outlook.com> <DM8PR11MB5719A7D43DC1162DDDE42378C9349@DM8PR11MB5719.namprd11.prod.outlook.com> <BYAPR05MB56544ACAB15C81EE01CDA472D4319@BYAPR05MB5654.namprd05.prod.outlook.com> <DM8PR11MB57194662A6BF247E80D1586AC9309@DM8PR11MB5719.namprd11.prod.outlook.com>
In-Reply-To: <DM8PR11MB57194662A6BF247E80D1586AC9309@DM8PR11MB5719.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.6.100.41
dlp-reaction: no-action
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=9ed0207a-3ff7-4c41-8ebf-7b139955e4f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=0; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-05-29T00:35:58Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4;
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none; dmarc.ietf.org; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [96.237.103.28]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 06b6db29-20dd-4282-a218-08d9303a6008
x-ms-traffictypediagnostic: MN2PR05MB6909:
x-microsoft-antispam-prvs: <MN2PR05MB6909D17CBA72AA39DB40BD22D4309@MN2PR05MB6909.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: AE4cK5pGwYypQjb9Jx/uZ5uAjTHUG6Z6vNjcFtQg0X8PCDPgwwfjj4S0FwLXIcl/hAcU1Cr5KhW3YNSj4CY29FTeixf+EuSciwR1TgnOUHxtbsPI9B6GOk1VFta5+tsg7/J/nnt/6UNIHegOlk7Sd5BGZ01W5PfAOt4+r2qQqnkHSCRXzduWS13W/U3scotZqbgmsV2zi1mhjVKCqTObpeQQ1AAT+cAhr/t4OpLVSV+sTU6PX+D+fId9Hc+JtugV/GPIGX2aEWTrLqLQG5RSqIdhbSBohpA67iwaeJTTLtd5ACRJs/ErH7xzp7g28+CvhW9Y2RDNSBDo6bZT+9eBX2TGVDGc3RhBztoYmQ/ntq3aUHoQy6VRJJ+gZt3clnvDifG7SarOX8OrrduTNnXuA5YPRcyty3lyOL+LzTAxpbYb5jzGPgSI/rLoQ9IZ4UgE62dO4vXfL8Im189wsomiSelIPo+UtzvVn2B+6JZuSXwkLw3lPac+DIQwPtnxqBDrMx+442z/c05QOe/JR1DeZQZiHp8EHwaH94lRCdf00foKVropAWO+/4Em0l2WDyrez4ltu6W6Zlu0+S3hAn7IdngyTE2o0d0e1j7Tf8bcuTgUpBmC5Bba8AWCFMZUTtqkGrLRYJEI5w5I3hLtsZ5U+O1nuwGcODktq63VylsfQPiXxUbmpFuDgGhhXEximAEdRan8czRRoPyrOX9OAVyo8JpVwSXe61d/O+pBtJdKM1m+bcg8J5LHII2fPVQn/g5+b5W3xftt461GrTWkCiZC1A==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5652.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(396003)(136003)(366004)(346002)(376002)(86362001)(83380400001)(33656002)(52536014)(2906002)(4326008)(30864003)(26005)(55016002)(9686003)(316002)(38100700002)(186003)(64756008)(66946007)(122000001)(5660300002)(53546011)(6506007)(76116006)(478600001)(66446008)(71200400001)(966005)(8676002)(66556008)(66476007)(8936002)(7696005); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: yiNTXkz5nLEPzEhsA27E8RghJjXPQKVFi2WjZYU0PymUA/jMbSBoAWhcWKgn915DECw+u1HZQY7Z9W4KdZhNckKmsJi3RDijU4zt+oGrLGeZy0Khnm4VdC0PHsrb4LxplD2d8UOCIoRc4h+XsZP+vaOioPD416j1OlxHXSVHggnyVJVGLweafRUE+WK2angJEk5J1I+AMpuHzU6ni0Oo3iHdszowGqlAAhlSYt4yJhP5n550SkWoq1ZlUrU5ElpDYhr0ZLizsiuP2MEpushVJ3BLwhA4KMGV+aSAOkZ8xzH2bhu0iDiEfqYLIesvLw03MkSnFlQ6T6UkGC2P1H9gH9vv+uhgO6MLj9hfN0ph1oTULH4WSo+0dkOXtNIDhfvsaOC/dkeAfP71+SS2E/3iYAVwtrDGhqpjQVdqaCl6SJ9fRBuA7o6btTqwyJCFJpfVtezrCujtDcftu8ub1atJ5KBEz5prDhkB+0ANNRBW7iR2aZPZmGO08U6jb3RWmR1B5V/CaoH0HT+b5M8TcOzooPlGQPmTeiTlCv0bFrLvxoxMViLLhwG4G/Z5PT9CkGBvAj4YYE0j4llhwpECbe2ZiO52O1bLdJCEcRPBXOigIUPy9FhHxstmXWSi44O8ArxE85KXu7v68pMJCIEYGXsV34feiCrhkg2UfB8j2K9QhBQ7NlklIfgQ4e7mW+wdswIbHJwBxTpDhMnJ1puhTgW3nM/RCa4CvJ5hJJWTAll4sldBniAJC8hz70HxDmI0EMPwGAHvAFfqHxH3rYQzCxIlmzk9FKkZwRgJYYRPmEvG9G/fJNVgkZmJxVaapWLUaByBS5EDGUK1vo7vthuffSTuaC7lNP+0oF/2g/Vrta8MGYwz1r5Cd68gSQd6VqAI3SY2MZHLsSGtXC7d7scWEe88cM4VqYjCtNaxy+QZy3tXpLhIx264M3mc6YlxQBSA2m1nDEbCwksVgQwtHcGutOldTnPMWhIvdQJY4CAwOXQ5tXj1Crk6B2tw4NPHMq/l76048zMV8TIPS2UjJ/gPVK+TDZhAEoy3AINPLg6zIYeDbuWIPgnGUI4YlGBL0ZGEGW3nMQkbYeYQHoOpcx44VuVRn3mF2VgU8KT9mhJeL8IF671j0UwA2yCSsnPm9A92ystjdQxubo8l4n9QbOAhaTgWizpYMB/yPPnaqgjOciTzk/vz4xBgA41XSYfhgn9IeEc29GJp2bxcVEv/WCG3MdFfiWsYWGiZGXUHLKkdzDpVt8RQcRysWDn38Z+FQXWUr45/Kf9vLFK26rQTtdGSIbrCN1qNaQefAvo1spYPV6u8E0mhC1qUo19I+rQAhDYrL86t
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL0PR05MB5652.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 06b6db29-20dd-4282-a218-08d9303a6008
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jun 2021 20:15:52.5231 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: N3DEKvlWNq08R6diSVa4V3E8K0U9z2Py1pSA6HMpYu9ARprXjqn7HIDipGlu7X4GgXvIlxQHrqDtbXxkf2qmQA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6909
X-Proofpoint-ORIG-GUID: U7ElQrKbmdVk34Cd1CMx1nyrLgJOfgBo
X-Proofpoint-GUID: U7ElQrKbmdVk34Cd1CMx1nyrLgJOfgBo
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-06-15_07:2021-06-15, 2021-06-15 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxlogscore=999 lowpriorityscore=0 malwarescore=0 adultscore=0 spamscore=0 suspectscore=0 bulkscore=0 phishscore=0 impostorscore=0 priorityscore=1501 clxscore=1015 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2106150126
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/YGpCEDU2Z9kqYlMo-sTEADkJVzs>
Subject: Re: [DMM] Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13
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, 15 Jun 2021 20:16:03 -0000

Hi Pablo,

Please see zzh3> below.

-----Original Message-----
From: Pablo Camarillo (pcamaril) <pcamaril=40cisco.com@dmarc.ietf.org>
Sent: Tuesday, June 15, 2021 3:03 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
Cc: dmm@ietf.org
Subject: RE: Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

[External Email. Be cautious of content]


Hi Jeffrey,

Inline with [PC3].

Cheers,
Pablo.

-----Original Message-----
From: dmm <dmm-bounces@ietf.org> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: lunes, 14 de junio de 2021 22:10
To: Pablo Camarillo (pcamaril) <pcamaril=40cisco.com@dmarc.ietf.org>
Cc: dmm@ietf.org
Subject: Re: [DMM] Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

Please see zzh2> below.

-----Original Message-----
From: Pablo Camarillo (pcamaril) <pcamaril=40cisco.com@dmarc.ietf.org>
Sent: Friday, June 11, 2021 10:15 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
Cc: dmm@ietf.org
Subject: RE: Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

[External Email. Be cautious of content]


Jeffrey,

Inline with [PC2].

Cheers,
Pablo.

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang <zzhang=40juniper.net@dmarc.ietf.org>
Sent: lunes, 7 de junio de 2021 14:48
To: Pablo Camarillo (pcamaril) <pcamaril@cisco.com>
Cc: dmm@ietf.org
Subject: RE: Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

Please see zzh> below.

-----Original Message-----
From: Pablo Camarillo (pcamaril) <pcamaril=40cisco.com@dmarc.ietf.org>
Sent: Friday, June 4, 2021 12:52 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
Cc: dmm@ietf.org
Subject: RE: Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

[External Email. Be cautious of content]


Hi Jeffrey,

Thanks for your email. Inline with [PC].

Cheers,
Pablo.

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang <zzhang=40juniper.net@dmarc.ietf.org>
Sent: martes, 1 de junio de 2021 17:39
To: Pablo Camarillo (pcamaril) <pcamaril@cisco.com>; dmm@ietf.org
Subject: Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

5.2.2.  Packet flow - Downlink

   The downlink packet flow is as follows:

   UPF2_in : (Z,A)                             ->UPF2 maps the flow w/
                                                 SID list <C1,S1, gNB>
   UPF2_out: (U2::1, C1)(gNB, S1; SL=2)(Z,A)   ->H.Encaps.Red
   C1_out  : (U2::1, S1)(gNB, S1; SL=1)(Z,A)
   S1_out  : (U2::1, gNB)(Z,A)                 ->End with PSP
   gNB_out : (Z,A)                             ->End.DX4/End.DX6/End.DX2

   ...
   Once the packet arrives at the gNB, the IPv6 DA corresponds to an
   End.DX4, End.DX6 or End.DX2 behavior at the gNB (depending on the
   underlying traffic).

Because of the END.DX2/4/6 behavior on gNB, the SID list and S1_out can't just simply use gNB. It must be gNB:TEID.
[PC] Do you think replacing all address with ones carved out of 2001:db8:: would help? Because based on this comment and the one below, I can see there might be a point of confusion here.

Zzh> I think gNB::TEID would be clearer, like how you say SRGW::TEID in 5.3.1.2. The gNB needs to use the TEID to do DX2/4/6.
[PC2] That is my point, the TEID does not need to be explicitly included in the SID.
[PC2] It is an IPv6 address that is associated to a particular TEID session. But TEID is not present.. therefore writing gNB::TEID would be misleading. See my point?
Zzh2> I don't mean that TEID is present in a GTP-U header. It is part of the IPv6 address (used for DX2/4/6 purpose). Writing it as gNB::TEID emphasize that the TEID information is embedded in the address, just like why you use SRGW::TEID in some examples.
[PC3] The TEID is not present on the IPv6 address used for the End.DX2, DX4, DX6 SIDs.
Zzh3> Could you elaborate how DX2/4/6 is done if TEID (or its mapped value) is not in the IPv6 address? For example, how does the gNB know if a packet is for UE1 vs. UE2? The gNB does not look up the inner (UE) IP address when forwarding (that's whole point of DX2/4/6).

In 5.3, for uplink traffic, the GW has End.M.GTP6.D for the UPF address B and the gNB does not need to know the existence of GW. For downlink traffic, the UPF knows there is a GW and put the GW::TEID in the SRH. Why not make GW invisible to UPF as well and just use gNB::TEID, and then have gNB/96 as End.M.GTP6.E on the SRGW? You can still put GW in the SRH to steer traffic through the GW.
[PC] That is a valid point. I'll think about it and get back to you.

5.3.1.1.  Packet flow - Uplink

   The uplink packet flow is as follows:

   UE_out  : (A,Z)
   gNB_out : (gNB, B)(GTP: TEID T)(A,Z)       -> Interface N3 unmodified
                                                 (IPv6/GTP)
   SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> B is an End.M.GTP6.D
                                                 SID at the SRGW
   S1_out  : (SRGW, C1)(U2::1, C1; SL=1)(A,Z)
   C1_out  : (SRGW, U2::1)(A,Z)               -> End with PSP
   UPF2_out: (A,Z)                            -> End.DT4 or End.DT6

Shouldn't U2::1 be U2::TEID? Even for the enhanced mode, TEID is still signaled and used - just that multiple UEs will share the same TEID.
[PC] I don't see the difference in between U2::1 and U2::TEID. It is a SID configured for a set of multiple UEs. Meaning, this is an illustration. So not sure I follow your point. Same as previous question. I think 2001:db8:: might be helpful in here...
Zzh> The AMF will signal different TEIDs for different UEs. While a local policy on SRGW could ignore the TEID, notice the following:
Zzh> 1. The UPF won't be able to distinguish those UEs, yet the use case could be that the UPF may need to put those UEs into different VPNs based on the TEID and now it can't any more. While the SRGB could have different policies to map different <B, TEID group> to different U2::X and the UPF would rely on X to distinguish the associated VPNs, that requires lots of management burden to configure those policies on the SRGB. It is much simpler to just put the TEID in the IPv6 address behind the U2 locator. In the transport underlay you can still transport based only on the locator. On the UPF, you may have individual TEID specific routes, or you can have routes that aggregate on the TEID part to achieve aggregation - that is no worse than having those different policies on the SRGB. In summary, it is better to simply put TEID after the U2 locator.
[PC2] The SRGW only aggregates traffic that belongs to the same context. You do not aggregate traffic of different tenants. This is not stated explicitly in the draft. I think I can add that.
Zzh> 2. This kind of aggregation is actually native to the GTP-U method - the packets are transported only based on the UPF address - so it is not an advantage that SRv6 brings.
[PC2] Disagreed. GTP-U does not aggregate at all. It performs routing based on IPv6 DA, but that is not TEID session aggregation. As stated in the other thread.. you can change GTPU to achieve the same thing, but GTPU today does not allow it.  :-)
Zzh2> Deferred to the other thread.

BTW, since you removed UPF1 in Figure 5, it's better to rename UPF2 to UPF1, and change U2 to U1.
[PC] I'm fine either way. Changed.

For 5.3.1.3, why is downlink considered stateless while uplink has some state? Aren't the same - just one converts GTP-U to SRv6 while the other does the opposite?
[PC] On the downlink, the SLA is provided by the source node UPF that has the state. Hence the SRGW is quite straightforward.
[PC] On the uplink, the SLA is provided by the SRGW, which needs to hold all the state.

Zzh> What are "all the state"? I see the following:

   When the packet arrives at the SRGW, the SRGW identifies B as an
   End.M.GTP6.D Binding SID (see Section 6.3).  Hence, the SRGW removes
   the IPv6, UDP, and GTP headers, and pushes an IPv6 header with its
   own SRH containing the SIDs bound to the SR policy associated with
   this BindingSID.  There is one instance of the End.M.GTP6.D SID per
   PDU type.
[PC2] The SRGW needs to store the SR policy that is going to be applied after the BSID operation. On the downlink there is no such SR policy.
Zzh2> For uplink, "B is an End.M.GTP6.D SID at the SRGW" and " There is *one* instance of the End.M.GTP6.D SID *per PDU type*". For downlink, "SRGW/96 is End.M.GTP6.E". As I see it, it's just one-to-one comparison? Are you saying that SID list is the extra state? It's just a single SID list anyway - unless that single instance of End.M.GTP6.D SID per PDU type actually look at more traffic information to produce different SID lists (and in that case you need to clarify it).
[PC3] Yes, the SID list is the extra state that needs to be stored.
[PC3] The SID list pushed depends only B -the node does not perform any classification or looks at traffic info to produce different SID lists-.
[PC3] It is expected to have one B, per PDU Session Type. However, this can change depending on operator needs (i.e., SLA); and indeed I could see one SLA for best effort, another for low-latency, another offering a redundancy service for urllc, ...
Zzh3> Does that mean the N2 signaling will use different UPF (B) addresses for different SLAs (since "The SID list pushed depends only B -the node does not perform any classification or looks at traffic info to produce different SID lists")? To me that is a change in the AMF function and needs to be clarified.
[PC3] In the downlink, the SRGW does not need to store the SID list.
Zzh3> That single SID list in a policy is insignificant (O(1)) when you compare the uplink/downlink state. What really matters more is having many different BSIDs/policies for different uplink SLAs. The text should reflect the latter point 😊

Zzh> B is the UPF address signaled from the AMF. So is it that for each <PDU type, UPF> tuple, there is one policy for *all* the UEs associated with that tuple? What is the granularity level of SLA you're referring to? How is it achieved if the granularity level is finer than the <PDU type, UPF> tuple?
[PC2] The operator may instantiate as many BSIDs at the SRGW as different SLAs it has.
Zzh2> But it says "There is *one* instance of the End.M.GTP6.D SID *per PDU type*"?
[PC3] I'll clarify that in the draft to say there may be more than one. That is wrong -as stated above-. At minimum, there is one per PDU type. But there may be more.

Zzh> 5.3.1.3 says:

   For the uplink traffic, the state at the SRGW does not necessarily
   need to be unique per PDU Session; the SR policy can be shared among
   UEs.  This enables more scalable SRGW deployments compared to a
   solution holding millions of states, one or more per UE.

Zzh> Since you use word "not necessarily", it means the state could be unique per PDU sessions. How is that done? As asked above, the state seems to be only per <PDU type, UPF>.
[PC2] You could assume that each different PDU has a different SLA, and hence a different SID list. That is quite unrealistic, and I would be quite surprised to see that. Instead, it would be quite common to share the same policy across different PDU Sessions.
Zzh2> My real question is - since "The operator may instantiate as many BSIDs at the SRGW as different SLAs it has", how it is really done (whether the granularity is at PDU session level or not)?
[PC3] The operator provisions at the SRGW as many BSIDs as different SR policies it may want to have. Each different SR policy has a different SLA. Up to here there is nothing specific to mobility (i.e. all is defined in the SR policy IETF draft).
Zzh2> How are the BSIDs assigned (with the unchanged N2/N4 interface), and how is that not contradicting "There is one instance of the End.M.GTP6.D SID per PDU type"?
[PC3] The BSID is an IPv6 address that is passed together with the TEID on the N2/N4. As stated before, there might be more than one instance of the End.M.GTP6.D SID. This I will change it in the draft.

Zzh3> Basically the AMF needs to give out different addresses for different SLAs (unless the SRGW does ULCL). That needs to be clarified.

Zzh2> Additionally, "a solution holding millions of states, one or more per UE" now does not seem to exist, so the comparison only adds confusion not value.
[PC3] To have per-UE SLA, you need to have state on a per-UE basis. Do you think there is no such network with a million of UEs?
Zzh3> The context is SRGW scaling. Is there a solution where an SRGW would hold millions of per-UE state? That's what I meant but I can let it go now.

5.3.2.1 has the following:

   When the packet arrives at the SRGW for UPF1, the SRGW has an Uplink
   Classifier rule for incoming traffic from the gNB, that steers the[PC] w
   traffic into an SR policy by using the function H.M.GTP4.D.

The SRGW is not a 5G NF, so the "Uplink Classifier rule" does not have to be the following (draft-homma-dmm-5gs-id-loc-coexistence):

    Uplink Classifier (ULCL):
       An ULCL is an UPF functionality that aims at diverting Uplink traffic, based on filter rules provided by SMF, towards Data Network (DN).

So, instead of ULCL, the SRGW could have an IPv4 route for the UPF address which steers the matching traffic to an SR policy with function H.M.GTP4.D. If that is done, then the following is not true:

   For the uplink traffic, the state at the SRGW is dedicated on a per
   UE/session basis according to an Uplink Classifier.  There is state
   for steering the different sessions in the form of an SR Policy.
   However, SR policies are shared among several UE/sessions.

Because we don't need per UE/session steering - we can just steer based on UPF's address (just like in IPv6 case).
[PC] If you steer based on UPF address, then you cannot apply a different SLA to traffic from different UEs. Hence the need to have per UE/session steering.
Zzh> So now you care about per UE/session steering 😊 Then what about other situations where you care about aggregations like in 5.2.3 😊
Zzh> The context is " 5.3.2.3.  Scalability" where it talks about that "There is state for steering the different sessions in the form of an SR Policy". For comparison, " 5.3.1.3.  Scalability" does not care about per UE/session steering. It seems that you use different criteria in different places 😊

[PC2] There is quite a difference in between 5.3.1 and 5.3.2. The mechanism defined for IPv6 interworking in 5.3.1 is based on remote steering (i.e. BSID). The mechanism defined in IPv4 depends on local policy at the SRGW. So the state is completely different in those two scenarios.
Zzh2> In 5.3.1, the gNB sends packets to B, and you treat B as a BSID on the SRGW. In 5.3.2, the gNB also sends to B, and I was saying that while you can't call the IPv4 address B as a BSID (since it is an IPv4 address), you can still "have an IPv4 route for the UPF address B which steers the matching traffic to an SR policy with function H.M.GTP4.D". To me, there is no need to be different between IPv4 and IPv6 (except that you can't call that IPv4 address as a BSID - but that's just a naming thing).
[PC3] Ok. I see your point. So basically you think we could define a BindingSID for IPv4 using an ULCL and a bunch of loopback addresses on the UPF. I do think that is doable from a technical point of view, however I guess the immediate feedback would be that the IPv4 address consumption could be large in proportion to the allocated address space. Any comment or consideration on that regard?

Zzh3> My point is that no ULCL is needed at all. Just have an IPv4 route for the UPF address and steer traffic through a corresponding policy, just like in IPv6 case (the only difference is that in IPv6 case you can call it a BSID).
Zzh3> As for "a bunch of loopback addresses on the UPF", don't you need something similar for IPv6? The AMF would give different addresses for different SLAs, though on the UPF the IPv6 addresses don't need to be tied to loopbacks - they can be viewed just as SIDs.
Zzh3> Well - ok the IPv4 address consumption could be an issue (you may want to clarify in the draft that's the reason for ULCL) - but how many different SLAs would you support, and if there are many then in the IPv6 case would you rely on AMF to provide different addresses or do the same as in IPv4 case and rely on ULCL?
Zzh3> Jeffrey


[PC] Also, as a correction, the IPv6 case does NOT steer based on the UPF address. It leverages a BSID to perform remote steering.
Zzh> Ok I was not strict on my language. The BSID is a locator of the UPF address, right?
[PC2] No. The Binding SID is defined in RFC8402.
Zzh2> Let me rephrase. In 5.3.1.1, the gBN sends to B, and " B is an End.M.GTP6.D SID at the SRGW". If you're saying that the policy associated with the B actually looks at the TEID or some other parameters to produce different SID lists for traffic steering, you need to clarify it. Regardless, 5.3.2.1 does not have to be different - gNB sends to B, and the SRGW can have an IPv4 route for B to steer traffic through the same policy as in IPv6 case - just that you can't call the IPv4 address B as a BSID anymore.
Zzh2> and please see the following in my initial emal:
"It seems that the only reason ULCL is used here is just that we don't call an IPv4 address a SID - but that does not mean we can't use an IPv4 route to steer traffic into a policy (isn't it the same thing that we use an IPv6 route for an address that we call SID)?"
[PC3] Already replied in previous block.

Zzh2> Jeffrey

5.3.3.  Extensions to the interworking mechanisms

   In this section we presented two mechanisms for interworking with
   gNBs and UPFs that do not support SRv6.  These mechanisms are used to
   support GTP over IPv4 and IPv6.

Only gNB, not UPF, right?
[PC] Not sure I follow your point. Interworking in between a GTP-U gNB, and an SRv6 UPF mainly, but it could also be used with a legacy UPF.

Zzh> 5.3 only presented interworking between SRv6 UPF and GTP-U gNB (not between SRv6 gNB and GTP-U UPF), right?
[PC2] Correct.
Zzh> I was wondering if the same GW could be used next to a GTP-U UPF. If yes, then why there is a need for "5.4 drop-in mode"?
[PC2] with subtle changes, yes, it could be used. This is defined in 5.4, hence indeed the paragraph below can be removed.

   Furthermore, although these mechanisms are designed for interworking
   with legacy RAN at the N3 interface, these methods could also be
   applied for interworking with a non-SRv6 capable UPF at the N9
   interface.

Are you referring to the following?
[PC] Yes

 gNB (GTP-U) -- SRGW1 ----- UPF1  -------  SRGW2 ----- (GTP-U) UPF2

What's the difference between SRGW1 and SRGw2? If there is, then the above paragraph is incorrect.
If there is no difference, why do we need drop-in mode (which has difference between SRGW-A and SRGW-B)?
[PC] SRGW1 and SRGW2 performs the opposite operation. The drop-in mode has on both ends GTP-U, and in the middle SRv6; which is slightly different. But from a dataplane perspective the SRGW of both modes are pretty much the same.
Zzh> The point is that SRGW1 and SRGW2 do perform different/opposite operations (that's why "5.4 drop-in mode" is needed). With that, the first and last paragraph in 5.3.3 (as I quoted in the earlier email) are not correct, right?
[PC2] I see your point now. Indeed, the paragraph should be removed.

Jeffrey

Juniper Business Use Only

Juniper Business Use Only

Juniper Business Use Only

Juniper Business Use Only

Juniper Business Use Only
_______________________________________________
dmm mailing list
dmm@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmm__;!!NEt6yMaO-gk!Ro1t2yZ3JOnFGW6sh3_9s5mMLnNp5LIThuN3YCm3IjdL2WaGqH8GiFHNIMqcKNnm$

Juniper Business Use Only

Juniper Business Use Only