From nobody Tue Mar 30 06:05:23 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF873A1172 for ; Tue, 30 Mar 2021 06:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=O+qa0DnH; dkim=pass (1024-bit key) header.d=juniper.net header.b=jMYh6uL4 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 UpstTF8NtRl6 for ; Tue, 30 Mar 2021 06:05:16 -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 9799C3A1166 for ; Tue, 30 Mar 2021 06:05:16 -0700 (PDT) Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 12UD0Ch7012364; Tue, 30 Mar 2021 06:05:14 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=lEYMtCaMmus/FZJsy7P0C3r4/TbdyAFjBlgs/AbQ3l4=; b=O+qa0DnHDJLkToM04sK+GQjNuYIDmMF907FgJh5WqPHaZwtek0nMyh7XtW/NiNczy+Hq ib54PivCSbcRTXQhjCRCtlYQ/zj3GeFm+GqRAj6GSYABKepHYpdK/7Hmst9xjEP2OI9q wX8MGT30C8wLo40kfP/jdVKaXf59zFwopyHmkCoOOUc5eYKcXJ2jGjYdLRSlHE/JcToT vD0mQfIakMvo2EZxsxnkuT+31tEFsTJQn4T7SPs0VRLzYYO9BM1B2gtiue3sBwmeImgl VYsAB2vi67lhTprMVaWo54G+ujT7ml5u+YVaz9+feHWdwxryl3mGDMfJemWsm7Yq8AeB TQ== Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2109.outbound.protection.outlook.com [104.47.58.109]) by mx0a-00273201.pphosted.com with ESMTP id 37kq2w1ct0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 30 Mar 2021 06:05:14 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FiIg5qU/ngSsovgm7jdRQI5xBI6mtZvTBt0qyWwtKQNUf9VWw0lMu0yxZliZdGvtCx8MrJ/CahdvN+TDK1yUhxfFl0M66hyyyeKH65RczSQqoc0cMk3rfVtX6wTqdh0cgBEXKCrgArmSgFI38Fz2Q8AnhS9v2OXATSMdZnwyFhgYMfoMIiIhP+B46o7htTwUW+gumbEPkf61XPB3vfsY/DE7CjgmzJxV3rVIJR+/C1+3sPxTaDiRpa0HZatvd8rdQZuJpTo1iBCGiPM0yH+Iu0hnNIyHf4IufKf2xWtZwcSUrowMV/R5LQVnRk5UcXk41+rDKM8lI73IdmJOYFoqKg== 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=lEYMtCaMmus/FZJsy7P0C3r4/TbdyAFjBlgs/AbQ3l4=; b=KiIAGY1oXmh6BZ6jPYkQqsLYiEOTgglPu9k+IY0cdsltOT0dVINuwTXV4CWIJbF1j9tVKCy+W7Q7cF0YqOm0GUnyzJ9og/yeLzWySs38At0xP4a1dc5xKsYUiIihAsEZ7bwQ9jeMjuKnk66Vk2/N0UpagGC13FRysbM8Wab92G/gEv/1vIuv8awcD/c5+20FqozXRzvY3xhXOVXF3VTaqhu2FCwyOswqLHpqRm8jPN5UQACZ6eHyi7YGv6LcTZlBCyo6TztR/uckfZ4/6kbWGtkH/PXE1SSAhFs8KF40Vx3MYKNWxH+N6OfzirdfTFnH1Ko4S1GygEJ4UolZg/D6Dg== 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=lEYMtCaMmus/FZJsy7P0C3r4/TbdyAFjBlgs/AbQ3l4=; b=jMYh6uL4YL5MpDm9ixzbZVSfz6wbLlv7qzaaeQZGaM8MqeZ8AVKAgej+yQBz3ZP8WE+XUtpXoCt4HCxwh+ZdNxbUPzL8RO3EiPVCnjKwINvLmN6o4qvihqxjYbJuVpsXjIeonhnbjpnh2YEbpM/c8O4Pc4UaK8rBeKnlLwInqnM= Received: from MN2PR05MB5981.namprd05.prod.outlook.com (2603:10b6:208:c3::15) by MN2PR05MB6528.namprd05.prod.outlook.com (2603:10b6:208:df::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3999.15; Tue, 30 Mar 2021 13:05:11 +0000 Received: from MN2PR05MB5981.namprd05.prod.outlook.com ([fe80::203e:7f1f:be91:161c]) by MN2PR05MB5981.namprd05.prod.outlook.com ([fe80::203e:7f1f:be91:161c%6]) with mapi id 15.20.3999.026; Tue, 30 Mar 2021 13:05:11 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Linda Dunbar , "Joel M. Halpern" , 'IPv6 List' , Kaippallimalil John Subject: RE: Questions/comments about draft-dunbar-6man-5g-edge-compute-sticky-service Thread-Topic: Questions/comments about draft-dunbar-6man-5g-edge-compute-sticky-service Thread-Index: AdciSsNyEeeG0fk2Tl2oPdOa//JdzQBK/mXgAEpNTUAABUo8MAABG5xQAABGD6AAAKlBMAAAYSJwAAAZJnAAAFna8AADH9oAAASmn/AAHtjmUA== Date: Tue, 30 Mar 2021 13:05:11 +0000 Message-ID: References: <712706464d4048c9840c4e62151dec5e@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.6.0.76 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=4c58a30e-b170-4481-b65b-a55e2c9c8fe0; 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-03-30T11:51:56Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [71.248.165.31] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 68864d7a-365b-4cc5-b4e4-08d8f37c7384 x-ms-traffictypediagnostic: MN2PR05MB6528: 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: G2tMrY2f1ZQA+/rOskUTrvepsB7DKWH5rayCL/lMjBFHdM9BsHHFoj/0e21ndgakYNHSHx8Bo8tBze9WMwPN8ra5eOiCjpmDaO/UrCMC/bgruGxgqS3+9D2qKorrY0OvujTsF3uY0UKax7ch6QzMVEMSLZhbWIQ5TofozsgK4aw7iWH81DVuNoFXUhmX6zpHs+6SIOOB611EX5qY4uWX2uPSw8EOoHEeFzceWnIKSY3bJFPOz/6t6b/DpuVoeDx2ECtuh18u2DI83p3QQAC1erYmzpZOg+sfQJ5ubQ6mD8wnbIJD311u/bFtv0DJeEWbflc2SwmXk0ejddqpC0BT4MhNODRyJErZHjgY79wT4rn8ib5YW75+6D+da21LOlCar1urYG/8UmJLuc4LEhjWU4M9tvCMFIzcP/wfcWw3ETQJpPCprMopyYTSumat36zWCpHWAv5Ftx+rRx5jCg6ap1dQI48SCbOcW/gvGOMwgAOVIDTnFF7DipVeYPxsufz1TMSUTzdHAn1bNaquCC6v/8T/9NtJhBpARGWi94KMCttqB3H7qQsZ6VIJueYAH1gvQgRR5qn+A3z/ZB3w8JTc730onAJlnx/Jsv/t49PMLje0mu8ZgAoSrrveLttyYh2L3kCgPzEg7/9oiXKW8IoT3/6iAZaDKEniNBbH0AEsXhUYhiz6ENJJC+hGb/e7CUd0Kkgoddx54E2N7AmnvjLwBpyjbe1ZkuE7ll7BsUgWop7m6viNS3dEQVD6NsF09rdz x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR05MB5981.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(39860400002)(136003)(376002)(396003)(366004)(76116006)(316002)(66946007)(8936002)(86362001)(52536014)(66446008)(5660300002)(71200400001)(8676002)(110136005)(26005)(66476007)(30864003)(64756008)(66556008)(66574015)(2906002)(186003)(38100700001)(55016002)(7696005)(9686003)(83380400001)(478600001)(966005)(45080400002)(53546011)(6506007)(33656002)(559001)(579004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?lCAoqFVW8piF5RN4gpJ/wX1b/XRUYPkEg3YXX9VdxOTTdkK4ptb6wCabPE84?= =?us-ascii?Q?kdhRIALkjIohP1HN75fRz9hTcpzkg9PC2MyAIfcsgBGx4igx3u7FvIqLLKL5?= =?us-ascii?Q?T9ywbhhrs9hreew3CEs93SyaiV24yyVRgp3CaHpYzIR/Qmm0jgE5bcpCxVoA?= =?us-ascii?Q?EESnRewDgFTgmzj2TiPY5BkaGIK2ODiq7yJIY3W7YNGMuvhWPy2tIQxhGTJG?= =?us-ascii?Q?LTO1bz6h7B1NT0LB9SHjJlvayMSIozgulPlHYBCYOvQL6pbqlZFs3K9OT1Iz?= =?us-ascii?Q?OPAb6nelxx748GS6UTEvCkuRH2GSVwziZsAKclrkjJhXbd4lL4l4wfzPsty+?= =?us-ascii?Q?dkuwdSTq2r6FU4hIjgTKvqjh4okjD6oQ9OygJAY5oWdW9Mypsh53leiWNELA?= =?us-ascii?Q?p0seAw0L596mFKTcXqWzmrw5Je/GjvLsNPegzqLNQJFCkPr8hHCjaG/M2hFB?= =?us-ascii?Q?aZ6/RHWAS4PIt9L3S0paEzB5Yk6a9VRQRKHis0GKHVUAunSOycwRZh4MSYcC?= =?us-ascii?Q?gc35cnyzZIGUZUGzs0rsZw8HErsNoJA/xmB/K6e4xXsWmr5yYUiUqplAZT90?= =?us-ascii?Q?4r8kUcgYoytL5xbHRnAki1Yx/t7VpEnQmNZU8Ziih/rTrYj6y0DMEEIi5jrq?= =?us-ascii?Q?q2Y9bhGaHoYhxpUem/51mmkzaoTTAspe+V3G38cpV6t9h5XoJqW4fju8uj7T?= =?us-ascii?Q?WWznpGVPqmnycvQf79eCCGDhH69kVWw1JYwPf+PTYr+9or4N6Z3zpGU1VNfw?= =?us-ascii?Q?M/N0IxVAbyToAYPu2/tY59aAntwi9lxPboRb6gqmcmunQvodqedYUblKIZWe?= =?us-ascii?Q?6eA3IaJPsU1DHJ0rodNFgJZvAqDwtNp6Pmg1cWDuhZxiIOarvtmoxm1f1M66?= =?us-ascii?Q?hnckyJqbVrlg180GYPslp9PmFOlgPvMTnjDR5p5PChlrfFjskZfxDc27nTP3?= =?us-ascii?Q?hGrd76R4MRzdVVLDUHrHOWPMBXtYYdVuBkRKUE+rU0VDsKVYY7f/FAyQzDwR?= =?us-ascii?Q?aN/uIPpn8Gdx6qbc0joSRdb0j27IL6sx6Yaq4rNBwROABX0G2YAwLUI+pZsw?= =?us-ascii?Q?lU0lmeRzCzMW1doBlvvpYi0YkZftYyyJUHugMKVwZB8oworpViUwdQBY0CqT?= =?us-ascii?Q?Zt3Sk3ispRO9aHQ/WLxnaOVfXsjzq7r27lZEKxFpr0pxz9ggiqBNhu6H9G8g?= =?us-ascii?Q?2ofmoxuU0kkcrPdKrswOcOWb+ckPjnT71JNpnFPzU7kwsk4QIhCTsb1jLj8Q?= =?us-ascii?Q?K0aMJ1OTAocdYkZvFXMxM0vacf7JxA5e+MKpdEuBFCHQQjPW3eR7mnT0ytoZ?= =?us-ascii?Q?GzJjkMU57o9eFJECoBa10gBC?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR05MB5981.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 68864d7a-365b-4cc5-b4e4-08d8f37c7384 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2021 13:05:11.1077 (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: ENTLT/BN9gbisF8VI1DxsCq3/UguYXvvtYemk8vaUrQHEjv65uIKLHGCtAirLFCyv6pXDVQVIUvbYy8E+nXzew== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6528 X-Proofpoint-GUID: J_LyNRwKldCbA4VP9kR8vZ6Hmg4bY9yg X-Proofpoint-ORIG-GUID: J_LyNRwKldCbA4VP9kR8vZ6Hmg4bY9yg X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-30_04:2021-03-30, 2021-03-30 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 malwarescore=0 clxscore=1015 adultscore=0 suspectscore=0 bulkscore=0 impostorscore=0 lowpriorityscore=0 phishscore=0 priorityscore=1501 spamscore=0 mlxlogscore=999 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2103250000 definitions=main-2103300093 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2021 13:05:22 -0000 Hi Linda, You're not "leverage network control plane" - you're adding complications t= o the network forwarding plane (and the control plane because you need to c= oordinate among the ingress routers) with that sticky-service-table with (S= ticky Service ID, Flow Label. Sticky Egress address, Timer) entries. The 5G= /MEC control plane solution I mentioned does not need a UE to query for a n= ew address when its location changes. The variation of that sticky-service-table based on (Sticky Service ID, UE = address, Sticky Egress address, Timer) is slightly better, because it could= be generalized to forwarding based on (source, destination), which is not = different from IP multicast (except that there is no replication). While th= at reduces the complication in the forwarding plane, it still has the scali= ng issue - you will still have a large table and you will still have to coo= rdinate among different ingress routers. Granted, with the trendy AI, the coordination can be more precisely - the 5= G system can predict where a UE is moving to and push the corresponding ent= ry only to the new ingress router and ahead of time. If the UE address does= not change after its anchoring UPF changes, the coordination can be simple= r (otherwise the new ingress router needs to be able to associate the old a= nd new addresses). Retaining the same UE address after relocation can be done, and it is docum= ented in " Solution #26: Persistent address allocation for mobile UEs that = need MEC access" of 3GPP SA2 TR 23.748. I did not get to defend it during t= he final stage of study but I still think it is a viable solution (and pref= erred for application servers that do not deal well with client address cha= nges) - would love to discuss that further with John on 3GPP SA2 mailing li= st. Having said all the above, I still believe it's the easiest and most scalab= le solution if the UEs are told by 5G/MEC control plane what true unicast a= ddress of the server or load balancer to use. Jeffrey -----Original Message----- From: Linda Dunbar Sent: Monday, March 29, 2021 5:16 PM To: Joel M. Halpern ; Jeffrey (Zhaohui) Zhang ; 'IPv6 List' Subject: RE: Questions/comments about draft-dunbar-6man-5g-edge-compute-sti= cky-service [External Email. Be cautious of content] Joel, I am confused of your statement. The problem I described is: An end node (e.g. a drone) moves constantly. There are multiple servers= hosted in Edge DCs close to Cell towers to process requests from the end n= ode to achieve ultra-low latency. It is not realistic for the end node to = send DNS query every time it anchors to a new Cell Tower. The suggested solution is to leverage network control plane to find the opt= imal server to serve the end node. You stated that "it is not at all clear that is the best answer or even a g= ood one". Why? Linda -----Original Message----- From: Joel M. Halpern Sent: Monday, March 29, 2021 1:56 PM To: Linda Dunbar ; Jeffrey (Zhaohui) Zhang ; 'IPv6 List' Subject: Re: Questions/comments about draft-dunbar-6man-5g-edge-compute-sti= cky-service Linda, you are assserting that the answer is "to leverage the network contr= ol plane". As Jeffrey has pointed out, given the problem you have described, it is not= at all clear that is the best answer, or even a good one. Yours, Joel On 3/29/2021 1:30 PM, Linda Dunbar wrote: > Jeffrey, > > The draft is to leverage the network control plane to determine which ser= ver is the most appropriate one for the device. > > You can definitely use the Controller to choose the optimal server. To > simplify the IP address allocation, the draft suggest using the Egress > router addresses as the proxy for reaching the desired server. We can > add a section to describe this scenario > > Linda > > -----Original Message----- > From: Jeffrey (Zhaohui) Zhang > Sent: Monday, March 29, 2021 12:20 PM > To: Linda Dunbar ; Vasilenko Eduard > ; Kaippallimalil John > ; 'IPv6 List' > Subject: RE: Questions/comments about > draft-dunbar-6man-5g-edge-compute-sticky-service > > Since it is for "sticky service", you don't want to get a new server addr= ess every time you move - unless the previous one is no longer appropriate.= That means it is best for a controller to determine which one to use both = initially and later when situation changes (when a UE relocates or server l= oad situation changes), and that does not necessarily mean it is always thr= ough DNS. > > Jeffrey > > -----Original Message----- > From: Linda Dunbar > Sent: Monday, March 29, 2021 1:15 PM > To: Jeffrey (Zhaohui) Zhang ; Vasilenko Eduard > ; Kaippallimalil John > ; 'IPv6 List' > Subject: RE: Questions/comments about > draft-dunbar-6man-5g-edge-compute-sticky-service > > [External Email. Be cautious of content] > > > Jeffrey, > > The Devices are moving consistently, it is not reasonable to require them= to consistently query DNS for the "correct" non-ANYcast address . > > Linda > > -----Original Message----- > From: Jeffrey (Zhaohui) Zhang > Sent: Monday, March 29, 2021 12:04 PM > To: Linda Dunbar ; Vasilenko Eduard > ; Kaippallimalil John > ; 'IPv6 List' > Subject: RE: Questions/comments about > draft-dunbar-6man-5g-edge-compute-sticky-service > > Even if you could get over the security/trust hurdle, using a controller = to let the UEs know which unicast non-anycast address to use is a much simp= ler/better solution. > > Jeffrey > > -----Original Message----- > From: Linda Dunbar > Sent: Monday, March 29, 2021 12:50 PM > To: Vasilenko Eduard ; Jeffrey (Zhaohui) > Zhang ; Kaippallimalil John > ; 'IPv6 List' > Subject: RE: Questions/comments about > draft-dunbar-6man-5g-edge-compute-sticky-service > > [External Email. Be cautious of content] > > > Ed, > > Yes, they are in one domain. Here is one example: > > 5G Connected devices, such as drones for fighting fires or natural disast= ers or robots in Industry 4.0 environments, need ultra-low latency respo= nses from their analytic servers hosted in the Edge data centers. To reach = ultra-low latency, there are multiple servers hosting the analytic function= s in the Edge DCs. > All the functions (including networking and analytics) and devices are ad= ministrated by one operator. Those functions might be provided by differen= t vendors, therefore needing interoperable solutions. > > Linda > > -----Original Message----- > From: Vasilenko Eduard > Sent: Monday, March 29, 2021 11:41 AM > To: Linda Dunbar ; Jeffrey (Zhaohui) Zhang > ; Kaippallimalil John > ; 'IPv6 List' > Subject: RE: Questions/comments about > draft-dunbar-6man-5g-edge-compute-sticky-service > > It could be the problem. > Because all SR RFCs and drafts clearly say: only inside the domain. > Else could be a huge security risk. UE could not be trusted. > Cross-domain security is the principal question that should be discussed = in SPRING first. > Current SR architecture does not try to resolve it yet. > > > Segment Routing in general and SRv6 in particular are claimed to be desig= ned for Trusted environments only: > - Segment routing architecture (RFC 8402) section 8 > - SRH - Segment Routing Header (RFC 8754) section 5 > - SRv6 Network Programming (draft-ietf-spring-srv6-network-programming-25= ) section 9 SRH RFC is especially verbal how to filter-out any SR-related i= nformation on the border of "SR domain". > Ed/ > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Linda Dunbar > Sent: Monday, March 29, 2021 7:09 PM > To: Jeffrey (Zhaohui) Zhang ; Kaippallimalil John > ; 'IPv6 List' > Subject: RE: Questions/comments about > draft-dunbar-6man-5g-edge-compute-sticky-service > > Jeffrey, > > We can definitely add the option of UE inserting SRH. I am just not sure = how many UEs or end devices will do those actions. If very few UEs can do t= his action, the solution itself is not useful. However, it doesn't hurt for= IETF to specify such a solution so that future IoT or 5G devices can have = a reference to do the actions. > > Another point, the number of Sticky Service is not large. The Ingress rou= ters are configured with the policies ( ACLs) to filter those flows. > > Linda > > -----Original Message----- > From: Jeffrey (Zhaohui) Zhang > Sent: Monday, March 29, 2021 9:18 AM > To: Linda Dunbar ; Kaippallimalil John > ; 'IPv6 List' > Subject: RE: Questions/comments about > draft-dunbar-6man-5g-edge-compute-sticky-service > > Hi Linda, > > You proposed two ways of providing "sticky services" - when a UE moves to= a new location, the ingress router at that new location will still route t= he packets of the same flow to the previous egress router. That flow cannot= be identified by the destination address alone, since it is an anycast add= ress that are shared by servers behind different egress routers. > > Essentially, you're trying to turn the ingress router into a load balance= r, especially with your option #2 (section 5, "tunnel based" solution). I d= on't think we want the routers to do that - while routers can make use of 5= -tuple for ECMP hashing, we don't want to make routers more complicated and= do forwarding based on a sticky-service-table with (Sticky Service ID, Flo= w Label. Sticky Egress address, Timer) entries. It's not only complicated b= ut also does not scale (we can discuss the scaling aspect wrt the flow labe= ls separately). > > The variation of option #1 that I suggested would be better, if the follo= wing were true: > > 1. The UE can insert an SRH > 2. The ingress router can trust the SRH from the UEs > > In that case, it would be better for the UE to learn the egress router vi= a 5G/MEC control plane, instead of relying on the egress router to put that= into the DOH of every server->UE packets for sticky services and for the U= E to retrieve that information from each incoming sticky service packets. O= ne thing I learned is that the entire 5G system is very much heavy with con= trol/management plane and I would think it is a much better option to provi= de that information to the UEs. > > On the other hand, once you go that way, the control plane can simply pro= vide the regular, non-anycast addresses of the servers instead of the egres= s router address. Then, all the problems disappear and corresponding propos= als are no longer needed, including the ones in draft-dunbar-idr-5g-edge-co= mpute-app-meta-data, and we only need existing simple routing functions. > > Thanks. > > Jeffrey > > -----Original Message----- > From: Linda Dunbar > Sent: Saturday, March 27, 2021 10:45 PM > To: Jeffrey (Zhaohui) Zhang ; Kaippallimalil John > ; 'IPv6 List' > Subject: RE: Questions/comments about > draft-dunbar-6man-5g-edge-compute-sticky-service > > [External Email. Be cautious of content] > > > Jeffrey, > > Thank you very much for the constructive comments. > Replies are inserted below: > > -----Original Message----- > From: Jeffrey (Zhaohui) Zhang > Sent: Friday, March 26, 2021 3:59 PM > To: Linda Dunbar ; Kaippallimalil John > ; 'IPv6 List' > Subject: Questions/comments about > draft-dunbar-6man-5g-edge-compute-sticky-service > > Hi Linda, John, > > When a UE (User Equipment) initiates application packets using the > destination address from a DNS reply or from its own cache, the > packets from the UE are carried in a PDU session through 5G Core > [5GC] to the 5G UPF-PSA (User Plan Function - PDU Session Anchor). > The UPF-PSA decapsulate the 5G GTP outer header and forwards the > packets from the UEs to the Ingress router of the Edge Computing (EC) > Local Data Network (LDN). The LDN for 5G EC, which is the IP Networks > from 5GC perspective, is responsible for forwarding the packets to > the intended destinations. > > A nit comment about "5G Core" above. When I first started learning 4G/5G = It took me a while to realize the 3GPP "core network" concept in vastly dif= ferent from what IETF people are used to. It's not about topology and now t= he "core network" functions are being more and more distributed into edges.= Therefore, in this context it may be better to simply strike the "through = 5G Core [5GC]" wording to reduce the confusion to some readers. > > [Linda] That is very true. Removed the term per your suggestion. 5G Core = refers to all the functions from Radio to UPF. > > 1.3. Problem #1: ANYCAST in 5G EC Environment > > Increasingly, ANYCAST is used extensively by various application > providers and CDNs because it is possible to dynamically load balance > across multiple locations of the same address based on network > conditions. BGP is an integral part in the way IP anycast usually > functions. Within BGP routing there are multiple routes for the same > IP address which are pointing to different locations. > > Not only BGP - but all IP routing protocols should work well with anycast= . My understanding is that BGP being integral part here is really that the = data network here is likely realized by VPNs over the same transport networ= k. Is that a correct understanding? > > [Linda] ANYCAST has traditionally been used for servers or loader balance= rs that are placed in geographically diverse locations, so that BGP alone i= s enough for the traffic in one region to be forwarded to one server. But = for the 5G Edge Computing where multiple Servers/load Balancers with the sa= me ANYCAST addresses are placed close proximity, IGP is needed. > > Of course, BGP does have flexibility in providing better/more control of = route selection than IGP does in the context of the companion draft-dunbar-= idr-5g-edge-compute-app-meta-data. > [Linda] Correct. > > But, having multiple locations for the same ANYCAST address in 5G > Edge Computing environment can be problematic because all those edge > computing Data Centers can be close in proximity. There might not be > any difference in the routing cost to reach the Application Servers > in different Edge DCs. Same routing cost to multiple ANYCAST > locations can cause packets from one flow to be forwarded to > different locations, which can cause service glitches. > > As pointed out later in this same document, modern routers support "Flow = Affinity" and should not cause packets of a flow on a specific router to be= forwarded to different locations. The real problem is when a UE moves to a= different location, the new router at that location may send it to a diffe= rent egress router. However, that is the "sticky service" problem described= in 1.4. > [Linda] Correct. > >>From draft-dunbar-idr-5g-edge-compute-app-meta-data, I understand that on= a specific router it needs to choose a location that can best serve an app= lication based on some non-routing factors. If 1.3 is really for that purpo= se, it should be reworded accordingly. As I mentioned in an earlier email, = the two documents should better align on the problem descriptions. > > Here is the overview of the End-Node based Sticky Service solution: > - Each ANYCAST Edge Computing server either learns or is informed > of the unicast Sticky Egress address (Section 3). The goal of > the network is to deliver packets belonging to one flow to the > same Sticky Egress address for the ANYCAST address. Section 4.1 > describes how Edge Computing Servers discover their > corresponding Sticky Egress unicast addresses. > - When an Edge Computing server sends data packets to a UE (or > client), it inserts the Sticky-Dst-SubTLV (described in Section > 4.2) into the packets' Destination Option Header. > - UE (or client) needs to copy the Destination Option Header from > the received packet to the next packet's Destination Header if > the next packet belongs to the same flow as the previous packet. > > I was really confused by "next packet". I finally realized you may be ref= erring to response packets from the UE to the server, and the "same flow" s= hould be "same service". Better wording is needed here. > > - If the following conditions are true, the ingress router > encapsulates the packet from the UE in a tunnel whose outer > destination address is set to the Sticky Egress Address > extracted from the packet's Sticky-Dst-SubTLV: > o The destination of the packet from the UE side matches > with one of the Sticky Service ACLs configured on the > ingress router of the LDN, > o the packet header has the Destination Option present with > Sticky-Dst-SubTLV. > > Wouldn't it be better for the UE to put in an SRH with one SID for the se= rver address and set the DA to be the egress router address? That way you d= on't need the ACL or the DOH (the Sticky-Dst-SubTLV information in the DOH= is not for consumption by the server anyway), and you don't even need tunn= eling or BGP (unless VPN is used - but that's orthogonal to this). Existing= SRv6 function takes care of it. > > [Linda] 3GPP has rejected using SRH in the 5G Core. We can think about us= ing them in the N6 interface. > > Also, the Sticky-Dst-SubTLV in DOH of the server->UE traffic would be bet= ter renamed as "return waypoint" for more generic purpose. > [Linda] that is interesting suggestion. > > 4.1. Sticky Egress Address Discovery > > To an App server with ANYCAST address, the Sticky Egress address is > same as its default Gateway address. > > To prevent malicious UEs (or clients) sending DDOS attacks to routers > within 5G EC LDN, e.g. the Sticky Egress address that is encoded in > the Destination option header in the packets sent back to the UEs (or > clients), a proxy Sticky Egress address can be encoded in the > Destination option header. The proxy Sticky Egress address is only > recognizable by the 5G EC LDN ingress nodes, i.e. the Ra and Rb in > the Figure 1, but not routable in other networks. The LDN ingress > routers can translate the proxy Sticky Egress to a routable address > for the Sticky Egress node after the source addresses of the packets > are authenticated. > > Why is the 4.1 title called "... discovery"? Does not seem to be about "d= iscovery". > [Linda] it is about remembering which Egress router was used for the flow= . Should it be "Sticky Egress Memory"? > > 4.3. Expected behavior at the UE > ... > Section 4 describes the network layer processing if UEs do not > perform the steps described here. > > Should be "Section 5". > > [Linda] Thank you. > > 5. Tunnel based Sticky Service Solutions 5.1. Ingress and Egress > Routers Processing Behavior > > The solution assumes that both ingress routers and egress routers > support at least one type of tunnel and are configured with ACLs to > filter out packets whose destination or source addresses match with > the Sticky Service Identifier. The solution also assumes there are > only limited number of Sticky Services to be supported. > An ingress router needs to build a Sticky-Service-Table, with the > minimum following attributes. The Sticky-Service-Table is initialized > to be empty. > - Sticky Service ID > - Flow Label > - Sticky Egress address > - Timer > > Editor's Note: > When a UE moves from one 5G Site to another, the same UE will have > a new IP address. "Flow Label + Sticky Service ID" stays the same > when a UE is anchored to a new PSA. Therefore, this solution use > "Flow Label + Sticky Service ID" to identify a sticky flow. Since > the chance of different UEs sending packets to the same ANYCAST > address using the same Flow Label is very low, it is with high > probability that "Flow Label + Sticky Service ID" can uniquely > identify a flow. When multiple UEs using the same Flow Label > sending packets to the same ANYCAST address, the solution described > in this section will stick the flows to the same ANYCAST server > attached to the Sticky Egress router. This behavior doesn't cause > any harm. > > It seems that the same flow label is used for traffic of the same service= in both directions. So who will assign the flow label? > [Linda] The "flow label" from the IPv6 header should be managed by the ho= sts & servers. > > If two UEs of the same service happen to use the same flow label, then st= icky service is not guaranteed. For example, initially they're anchored at = different UPFs, and UE1 traffic is sent to egress router 1 while UE2 traffi= c is sent to egress router 2. When UE 1 relocates to the same UPF as UE 2's= , its traffic will be sent to egress node 2 because the same flow label is = used. > > Therefore, there should be a central controller to assign flow labels bas= ed on UE id, and the UE id is not based on IP address (since it could chang= e). > [Linda] Since the "Flow Label" is randomly generated (by Host OS), the ch= ance of two UEs reaching the same service having the same Flow Label is ver= y small. We can explore the option of getting the Control Plane involved. > > Note: since there are only small number of Sticky services, the > Sticky-Service-Table is not very large. > > With the above understanding, the table could get large? > [Linda]? > > When an ingress router receives a packet from a UE matching with one > of the Sticky Service ACLs and there is no entry in the Sticky- > Service-Table matching the Flow Label and the Sticky Service ID, the > ingress router considers the packet to be the first packet of the > flow. There is no need to sticking the packet to any location. The > ingress router uses its own algorithm to select the optimal egress > node as the Sticky Egress address for the ANYCAST address, > encapsulates the packet with a tunnel that is supported by the egress > node. The tunnel's destination address is set to the egress node > address. > > If a UE was using egress router 1 and it relocates to a new UPF, the new = ingress router will likely have no corresponding entry for it? What if the = new ingress router pick egress router 2? > It seems that the ingress routers need to pre-exchange entries in the tab= le? > I see it's discussed later that the routers do exchange the information. = It should be mentioned up front when the table is introduced. > [Linda] Would Adding a reference be enough? > > When an ingress router receives a packet in a tunnel from any egress > router and the packet's source address matches with a Sticky Service > ID, the egress router address is set as the Sticky Egress address for > the Sticky Service ID. The ingress router adds the entry of "Sticky- > Service-ID + Flow Label + the associated Sticky Egress address + > Timer" to the Sticky-Service-Table if the entry doesn't exist yet in > the table. If the entry exists, the ingress router refreshes the > Timer of the entry in the table. > > When the ingress router receives the subsequent packets of a flow > from the 5G side matching with an Sticky Service ID and the Sticky- > Service ID exists in the Sticky-Service-Table, the ingress router > uses the Sticky Egress address found in the Sticky-Service-Table to > encapsulate the packet and refresh the Timer of the entry. If the > Sticky-Service ID doesn't exist in the table, the ingress router > considers the packet as the first packet of a flow. > > The above is what leads me to believe that the flow label is the same in = both directions. > [Linda] they don't have to be the same, do they? > > 5.3. Scenario 2: With communication with 5G system > ... > The ingress and egress router processing are the same as described in > Section 5.1 except a flow is now uniquely identified by the "Sticky > Service ID" + "UE address" instead of "Sticky Service ID" + "Flow > Label". > > This confirms my earlier understanding for scenario 1 that "there should = be a central controller to assign flow labels based on UE id, and the UE id= is not based on IP address (since it could change)" and that the table cou= ld get large. > > Of course now for scenario 2, you're not using the flow label any more. W= hile the table only contains entries that this ingress router actually need= , the following are still true: > - The table could still get large (if the number of attached UEs for > the sticky services is large) > - On demand fetching of the table entry may not be fast enough > > Additionally, instead of "scenario", "option" or "solution" would be a be= tter wording. > [Linda] Good suggestion! > > More importantly, this stateful flow steering based on the additional tab= le is just too heavy and complicated. Why not simply have the UEs support S= RH so that traffic will be routed via the desired egress router using stand= ard SRv6 mechanism? > [Linda] It is not realistic for UEs (your smart phone) to support SRH. > > Jeffrey > > > -----Original Message----- > From: Jeffrey (Zhaohui) Zhang > Sent: Thursday, March 25, 2021 3:46 PM > To: Linda Dunbar ; Kaippallimalil John > ; IPv6 List ; > idr@ietf. org > Subject: questions about > draft-dunbar-idr-5g-edge-compute-app-meta-data and > draft-dunbar-6man-5g-edge-compute-sticky-service > > Hi Linda, John, > > I have the following questions. > > The two related drafts listed the following three problems respectively: > > 1.3. Problem#1: ANYCAST in 5G EC Environment.............. 6 > 1.4. Problem #2: Unbalanced Anycast Distribution due to UE Mobilit= y.................................................. 7 > 1.5. Problem 3: Application Server Relocation............. 7 > > 1.2. Problem #1: ANYCAST in 5G EC Environment.............. 4 > 1.3. Problem #2: sticking to original App Server........... 5 > 1.4. Problem #3: Application Server Relocation............. 5 > > Why is problem #2 different in the two drafts? Is it true that none of th= e two drafts address problem #3? > The idr draft talk about "soft anchoring" problem and solution - how is t= hat different from the "sticky service"? > > Thanks. > Jeffrey > > Juniper Business Use Only > > Juniper Business Use Only > > Juniper Business Use Only > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://urldefense.com/v3/__https://nam11.safeli= nks.protection.outlook.com/?url=3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__htt= ps*3A*2F*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2F= urldefense.com*2Fv3*2F__https*3A*2F*2Fnam11.safelinks.protection.outlook.co= m*2F*3Furl*3Dhttps*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fipv6*26amp*3= Bdata*3D04*7C01*7Clinda.dunbar*40futurewei.com*7C4209e8a9acae47b96d1808d8f2= d16b8d*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637526328578769822*7CUn= known*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ= XVCI6Mn0*3D*7C1000*26amp*3Bsdata*3DA39pqHVUBFsssO3DLSqrTUtPpcXAr*2F8pi*2Bmw= *2BtIJNME*3D*26amp*3Breserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6y= MaO-gk!QWI34EOzIdgzRLkkdD3rdv_fn4CLHXnnMvDpOOeQB4ELlElbfawu6WXv0nbjgi-z*24*= 26amp*3Bdata*3D04*7C01*7Clinda.dunbar*40futurewei.com*7C2b126cc5be8541bd43c= c08d8f2d4a7ab*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C6375263424630122= 56*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi__;JSUlJSUlJSUlJSUqK= ioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiUlJSoqKioqKioqKio!= !NEt6yMaO-gk!VemUe-2PHPVnuVFBu0NeOKMAx3tulW_X0zDToehm7avqQhBqbE3FDykd8nYVAq= HW$ > > V2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000%26amp%3Bsdata%3DaOw1DkDc > Qu0*2FmMi6RfWlUyRcLB2jRcsbBAhcpoaX5yE*3D%26amp%3Breserved%3D0__%3BJSUl > JSUlJSUlJSUqKioqKiolJSUqKioqKioqKioqKiolJSUqKioqJSUlJSUlJSUlJSUlJSUlJS > UlJQ!!NEt6yMaO-gk!Q-hLtDzPuot4CQsvyUhfrEcNgHIIBEdRDT4RgyHgVCE1f5Vt6Dlv > zYC-o7693kZ1%24&data=3D04%7C01%7Clinda.dunbar%40futurewei.com%7C67c9 > 07b1d8e643cc5a5108d8f2d6f104%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C > 0%7C637526352290503133%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ > QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DBe%2FU8Mh > JT%2BA5b83e8ZLFCeamlBcSoit3SJ6Xk3X9%2Bz8%3D&reserved=3D0 > -------------------------------------------------------------------- > > Juniper Business Use Only > > Juniper Business Use Only > > Juniper Business Use Only > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: > https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.co= m/?url=3Dhttps*3A*2F*2Fwww__;JSUl!!NEt6yMaO-gk!VemUe-2PHPVnuVFBu0NeOKMAx3tu= lW_X0zDToehm7avqQhBqbE3FDykd8ujmRF-e$ . > ietf.org%2Fmailman%2Flistinfo%2Fipv6&data=3D04%7C01%7Clinda.dunbar%4 > 0futurewei.com%7Ca73842e8d0e7473e591d08d8f2e43b9f%7C0fee8ff2a3b240189c > 753a1d5591fedc%7C1%7C0%7C637526409383434704%7CUnknown%7CTWFpbGZsb3d8ey > JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C100 > 0&sdata=3DqkqfI%2B3ZLo76yZFXDIxUxjfwyhA5MNJIqUwzUyTGXqc%3D&reser > ved=3D0 > -------------------------------------------------------------------- > Juniper Business Use Only