Re: [Idr] What do you think about this description of Path Selection added to draft-dunbar-idr-5g-edge-compute-app-meta-data?

Linda Dunbar <linda.dunbar@futurewei.com> Thu, 11 February 2021 18:27 UTC

Return-Path: <linda.dunbar@futurewei.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E473A1830 for <idr@ietfa.amsl.com>; Thu, 11 Feb 2021 10:27:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.09
X-Spam-Level:
X-Spam-Status: No, score=-2.09 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_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 mumul1FnAoZm for <idr@ietfa.amsl.com>; Thu, 11 Feb 2021 10:27:34 -0800 (PST)
Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700106.outbound.protection.outlook.com [40.107.70.106]) (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 CAC4B3A1822 for <idr@ietf.org>; Thu, 11 Feb 2021 10:27:34 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WN9X+k3hufIalImVh15dxzy9FTeTTXR1rgH1sdc+AMXr5yM/GAQQTya+ct3XkwtZs/1M4q8QA9KRQVBjp19gtE7YkUpb8d0lyrUCb6RHNM4kqgrjqEZ7m78B2esKBW8wlyg4BFSwXy0mlTJu+3wCFF3T71Kv7VbQYBe3lMP+RAYNv716qbKpXaAGQHyjxmRZ44Agf+zuWOZgU0mOwPy2zV6hGyxbCeroOwQqtGgR/u3qub/U8c1MhR1YV82tqxTX+RePpEanCX6wU/8GggKWGolLL7pRUvLFQt/QbV8DKwzJ2tNX2PU2/AY1nAewUFkz2J/+7chFHshTj3AlLp2XVQ==
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=Ij6rS/qnmHmGxzvSEL/AqKQpv9T15nCYIH1PY3bMCQU=; b=dLheLg56m+39R6CPjFo4vQwDYAM1sLZoFcZMtnKkyMPqLa9aqidJFhODpdpotx3rrCHBvcRAnqQsQ3NzTcSMKQmJhmJzGd6/xi5l9LL2ugZA9zyAdXE870YtwujHkEmV+rcJ0QAsOZw7dLzegKIACxjyAxL0XFeGSVhdUn6U8eMzbcL03JHAMznBtDOqtazRrmIiCtPpUFViiZPl9HY9Lc7vdPlPXx9201alYG8mbkS0tkA1gazx1qSQcAjueF5X7XG50AR8shhu0GlNKmEjuD4YCeEZVpAlxo5DOSrx/fAdLp+hDB7gjFcP9fb7t5PVtXOfGBUMM+swMRoLznwFuw==
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=Ij6rS/qnmHmGxzvSEL/AqKQpv9T15nCYIH1PY3bMCQU=; b=qcGXOfzZDRbE2dgSxlYhYO4cDduywJ7qawp5jDyPAbnyf6jefG+KeBKFdqXzwDlwsEv1jsqbqimgJC4USdSpXHgKtkxzsdLddrcTMXGj7ZOARQH9KdyXtgDcyOZ0z1mj3eX7s1r+ZAwHoKspBNAb8Y3WHti9BIMvlEYW5oSeOVo=
Received: from (2603:10b6:805:55::16) by SN6PR13MB2366.namprd13.prod.outlook.com (2603:10b6:805:5e::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.11; Thu, 11 Feb 2021 18:27:30 +0000
Received: from SN6PR13MB2334.namprd13.prod.outlook.com ([fe80::3050:546b:c47:a42a]) by SN6PR13MB2334.namprd13.prod.outlook.com ([fe80::3050:546b:c47:a42a%6]) with mapi id 15.20.3868.011; Thu, 11 Feb 2021 18:27:30 +0000
From: Linda Dunbar <linda.dunbar@futurewei.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, "idr@ietf.org" <idr@ietf.org>, Aijun Wang <wangaijun@tsinghua.org.cn>, "Acee Lindem (acee)" <acee@cisco.com>, Stephane Litkowski <slitkows.ietf@gmail.com>
Thread-Topic: [Idr] What do you think about this description of Path Selection added to draft-dunbar-idr-5g-edge-compute-app-meta-data?
Thread-Index: AdcAJLWeUfv0ky3LQFuFwq1fq3rRrgAbepcAAAI7ODAAAJtcAAAA3Zkw
Date: Thu, 11 Feb 2021 18:27:29 +0000
Message-ID: <SN6PR13MB23345D4B21D721898459B822858C9@SN6PR13MB2334.namprd13.prod.outlook.com>
References: <SN6PR13MB233492DA35C3A1537CC64FEC858C9@SN6PR13MB2334.namprd13.prod.outlook.com> <feafccdf-82c5-6adf-84d0-7b05c326c6de@joelhalpern.com> <SN6PR13MB2334F385DE865FEEB56A26F2858C9@SN6PR13MB2334.namprd13.prod.outlook.com> <6a0a7d64-5aa6-0420-ea18-8528a4fbe23f@joelhalpern.com>
In-Reply-To: <6a0a7d64-5aa6-0420-ea18-8528a4fbe23f@joelhalpern.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: joelhalpern.com; dkim=none (message not signed) header.d=none;joelhalpern.com; dmarc=none action=none header.from=futurewei.com;
x-originating-ip: [2603:8081:1700:ab:a4de:5b27:bcb7:c010]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f2393504-41df-4a85-623b-08d8cebab0e6
x-ms-traffictypediagnostic: SN6PR13MB2366:
x-microsoft-antispam-prvs: <SN6PR13MB2366838C07CB57EF0EB229D6858C9@SN6PR13MB2366.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 3fJqEbS264Ky6JUw0rP0pLOhLBh41YLi5fnxCEJpsRaXOU+som25e5hmKXDBSvyLoLx/dqjEX5qSrsNr3QHnipgUbVtdyJhjY5Wkk8kQ65Ic5ot5GPG+QP1UeUVTsFSNJIYgTEZoh0EKjelGWon/pp+7maQa2Z5C9L/OA1z13kHHmsHabf0b9ib+XjDGumil0B/4p2MXIQtC0tHVgbGzorbNmW/AWEETyFygL7BI0HzwnayWoBnDjzruVym/oNivEjsb+MlR7PQFPmnkF/ydoqaqxrrA8Im8/vpKrWOPdATXdjU5umP2ab3Cr5VXKYAwdNYEtaCtfESdqaK71eX5SPZYOWeLOlkb0YC1I2E0VWKu1fJdplFTtMONDtBJn40eGGUDQsIybzbyo8v3FRDvYQfj8H3xKUxfSNzz1e4UASzfMwQUJ+KMCSioe2OCYe/ksZZvNxPH5311mmS5K7XkblQOU1exx16aNtlVFg4DiHkDHWY92cwpNpndbUzy3cBr73MxVWuJr0NkDs8+wWqA8uefgHGDzVvmtG6AHl7pPXuuzZQkdmYm6Gten/vxcbocnAbQ7PqpwRGfpks7VMu4MRXCiRbW/iE6ZDi5SAgzFSo=
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)(396003)(346002)(39840400004)(136003)(366004)(376002)(7696005)(52536014)(66946007)(64756008)(2906002)(66446008)(76116006)(966005)(53546011)(6506007)(478600001)(83380400001)(5660300002)(71200400001)(66574015)(8936002)(66556008)(86362001)(45080400002)(44832011)(9686003)(316002)(110136005)(33656002)(186003)(55016002)(8676002)(66476007); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: 74y4hBUhzL8VUPROtYXNcHuIJ8+tdprf1TkYeWWpQ/C9djc8mu+rxq+kSpwY6HWi5T5mAveuenW1JUKhPAUGNqgdOxHTPSUO+XEBKEOq934mDz1loREVSU/ARCDZTWdq/ZzFDBM9wVa7oB06B4D8FiV3YH7GXL+jtN4ExNhSh/iiNrzp4KuWzJcAsuk9cPtSdgVWmg+8TGpMnKn79hqLss0xApxnQa6/mWjZFIysqb871Tg5nFKp89dllT8/v+4B1vbGCQ38KCCozC/BifbPr0/oYRX3JjwAJ9yK7xycIAMNqdIpbb2Qmj5O/wDvCfe3x9MCAgtkewyL62Vc/tvgtfvSMGPlviiLxmOTIp+psMHddaEJ37abcUvPEMV9CzrxtVeSEbkckWgs+3myR00N5vH96GNNkBhdu2rfFIiVmyy5C8KGLtCKc6VkMrDiWJasUF0C8zp7ABMb3oTFxyCnN0ip66ts16P32Hg4vHCO1bgJ6GE0vvwvauU6+3H6Y/KkL4UCWQ7t543fBJnDoOT4ZF6CPJAUFIM9r7omdzdCSBMJQUG/K5hNOuf9/74qxyzkpOnspcLYjIgWvothF1yATp1lYMMxe8TV7iFLhsAkiZH4CKlS+EcOHX3RRrPoSkxpdZSKPNB0uJvNIktHinuoBCzyOYlGsvJjtL8KUp2uv8KjYBuFnMFQXKpNQYFakNil8RbvLD12rzUz4UQZ3YHHHLQ/jCLZUQ8riiO6eJMSwBXYQQ8sZ0qOlDFKBXip5OwNIfDMw0wh7sU0Xl09Z2ZmxeQ6zCAfOHWrjWcqhyFpESABlLg8mqbiWpDH4a/344PuVPZac1pDn5oBXXP+VG650B0PY4yoG6XNzpd3y32o0PVT4t6pkXmd907ta4OHBG2NuOgRD0YNBxKkdx/S86NvRpG+mgPVZrP/ZSywOUZMrkXEZD0olWw1cjjapBujxHi1ZCdntdk/fUVNMrN2Tn91Ckaga6/12l7h63o9q6nQorsilgvpROEFS8sZOLH11hCZzM55bP9soStPnvM/hQW28VUejCpCKECwDicNzZZhnj5WO2vOXkVpjEs3SuGQu6BXpzNKWYqIGwAWw7SIMbh2YJ8JSZSQD4HzpYbtStibJmjKY0du7SdetI7IAwqN9hKu26rv8o+jQ/kUlz3SRb9pCTBHRvxcnMwFehQILbeDeo6TRoVj6XLj+ErmfTubBQvMUas84uvfeaGo5RaFCVRMmzThk6G9St75UaQVktn+ML910qrG5RSPhf0L+gjft+fNrdyui8VrSFOre2L9T0TEnyCkA9N6u5m1EJNDUUsq1GuqHybGaDXzWrIziyQL6g0CzUKswiA5phP4nOIfyT69JHXSylB88WXz+7Ui/8+18UNuDbu6N055ofrzHj8Y72dt
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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: f2393504-41df-4a85-623b-08d8cebab0e6
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Feb 2021 18:27:29.7593 (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: 8QXUBxOLTpNqt6jKlacRw5eSgkXq4lsq6dX8yhJz1W6L3/x68C4SfndeTtx0gCodNTpRiD18lK6GQKMz2N6y6g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR13MB2366
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/neWnJQiRAzZQui14Zu_qFF6HuHg>
Subject: Re: [Idr] What do you think about this description of Path Selection added to draft-dunbar-idr-5g-edge-compute-app-meta-data?
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Feb 2021 18:27:37 -0000

Joel, 

Now I understand where our communication misaligned. 

There are 3 separate things:
1. When a new flow comes to an ingress node, how to select the optimal egress router to reach an ANYCAST server.
2. How Ingress node keeps the packets from one flow to the same ANYCAST server, 
3. When a UE moves to a new Cell Tower, method to stick the flow to the same ANYCAST server, which is required by 5G Edge Computing: 3GPP TR 23.748. 

You are talking about Item 2 above, aren’t you? 
The Item 2 above, a.k.a. Flow Affinity, or Flow-based load balancing, is supported by many commercial routers. There is no need for additional attributes. For example, https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/lanswitch/configuration/xe-3s/lanswitch-xe-3s-book/lnsw-flow-portchannel-load.html 
https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/data-flow-affinity-edit-chassis.html

draft-dunbar-idr-5g-edge-compute-app-meta-data states that the ingress node, i.e. the router Ra/Rb which are adjacent to 5G UPF (or Packet Session anchor point-PSA), can use Flow ID (in IPv6 header) or UDP/TCP port number combined with Source Address to enforce packets in one flow being placed in one tunnel to one Egress router.  All other nodes in the network don’t need to take any extra action.  
Does it address your concern?

The Path Selection Behavior added is for the Item 1 above. 

The draft-dunbar-6man-5g-edge-compute-sticky-service is for Item 3 above. 

Thanks, Linda

-----Original Message-----
From: Joel M. Halpern <jmh@joelhalpern.com> 
Sent: Thursday, February 11, 2021 11:48 AM
To: Linda Dunbar <linda.dunbar@futurewei.com>; idr@ietf.org; Aijun Wang <wangaijun@tsinghua.org.cn>; Acee Lindem (acee) <acee@cisco.com>; Stephane Litkowski <slitkows.ietf@gmail.com>
Subject: Re: [Idr] What do you think about this description of Path Selection added to draft-dunbar-idr-5g-edge-compute-app-meta-data?

Linda, changing towers is not the only case which needs stickiness. 
Given that Routing can change, and the attributes of servers can change, the whole system needs stickiness.
And once you have solved that level of stickiness I believe it is almost inherent that one no longer needs to put the application attributes or any enhancements to anycast into routing.

Yours,
Joel

On 2/11/2021 12:39 PM, Linda Dunbar wrote:
> Joel,
> 
> Thanks for your comments. Replies are inserted below:
> 
> 
> -----Original Message-----
> From: Joel M. Halpern <jmh@joelhalpern.com>
> Sent: Thursday, February 11, 2021 10:26 AM
> To: Linda Dunbar <linda.dunbar@futurewei.com>; idr@ietf.org; Aijun 
> Wang <wangaijun@tsinghua.org.cn>; Acee Lindem (acee) <acee@cisco.com>; 
> Stephane Litkowski <slitkows.ietf@gmail.com>
> Cc: draft-dunbar-idr-5g-edge-compute-app-meta-data@ietf.org
> Subject: Re: [Idr] What do you think about this description of Path Selection added to draft-dunbar-idr-5g-edge-compute-app-meta-data?
> 
> Given the importance of managing all of selectivity, proximity (sometimes), and stickiness (so you don't move users from one service instance to another unless you also move the application state),...
> 
> [Linda] The Stickiness of binding one UE to the same Server when the UE moves to a different Cell Tower (i.e. anchored to a different UPF/PSA) is NOT conveyed by routing protocol.
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-6man-5g-edge-compute-sticky-service%2F&amp;data=04%7C01%7Clinda.dunbar%40futurewei.com%7C4692baaedc1944adbf6808d8ceb51eb4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637486624592889060%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=ZbV%2FiRJRpgPRxRkizYxeKLJilBj9U%2FtEGkF38aEwM7Q%3D&amp;reserved=0  describes approach to achieve stickiness , either by Hop by Hop or Destination Optional header.
> 
> 
> WHy would we put this information in routing?
> Yes, the information is needed.  But the full set of rotuers seem the wrong place to manage this behavior.  It might belong in edge routers, or in end devices, but not throughout the system.  So again, why put all this dynamic overhead into the routing system, burdening all rotuers.
> [Linda] The AppMetaData is only sent to the Edge Nodes which are interested in the service.
> 
> 
> Yours,
> Joel
> 
> On 2/10/2021 10:32 PM, Linda Dunbar wrote:
>> Stephane, Acee and IDR WG:
>>
>> During the IETF109 session on
>> draft-dunbar-idr-5g-edge-compute-app-meta-data, both of you pointed 
>> out that there should be a section describing the forwarding plane 
>> behavior, such as how does the route selection decision is made or 
>> changed with the additional information carried in  the AppMetaData.
>> AiJun also pointed out needing this description in the IDR mailing list.
>>
>> We plan to add  this subsection. Is it good enough?
>>
>>
>>      3.5BGP Path Selection upon receiving AppMetaData
>>
>> UEs anchored to PSA1 (5G UPF) and PSA2 (5G UPF) all need to 
>> communicate with S1:aa08::4450, which is the ANYCAST address with the 
>> servers attached to R1, R2, R3 and R5.
>>
>> Packets from the UEs anchored to PSA1 will ingress to R-PSA1 (Ingress 
>> router); Packets from the UEs anchored to PSA2 will ingress R-PSA2.
>>
>> Assume that both R-PSA1 and R-PSA2 have BGP Multipath enabled. As a 
>> result, the routing table in either of them would look like: Dst
>> Address: S1:aa08::4450   ---- resolved via NH: R1, R2, R3, R5
>>
>> Based on BGP AppMetaData TLV, let’s say local BGP Compute Application 
>> Plugin for AppMetaData finds R1 is the best for the flow S1:aa08::4450.
>> Then this Compute Application Plugin can insert higher weight for the 
>> path R1 so that BGP Best Path is locally influenced by the weight 
>> parameter based on the local decision.
>>
>> Just to refresh what we discussed in IETF109:
>>
>> Thank you very much.
>>
>> Linda Dunbar
>>
>>
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
>> ietf.org%2Fmailman%2Flistinfo%2Fidr&amp;data=04%7C01%7Clinda.dunbar%4
>> 0
>> futurewei.com%7C47fa57e5844749e05e3f08d8cea9c541%7C0fee8ff2a3b240189c
>> 7 
>> 53a1d5591fedc%7C1%7C0%7C637486575848772996%7CUnknown%7CTWFpbGZsb3d8ey
>> J
>> WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C100
>> 0 
>> &amp;sdata=75pkqbg6z75Ji3MOtZhBdz8wAMrm9FNQg0i7Pwk8IEo%3D&amp;reserve
>> d
>> =0
>>