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

"Joel M. Halpern" <> Thu, 11 February 2021 16:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 01D483A1732; Thu, 11 Feb 2021 08:26:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.121
X-Spam-Status: No, score=-2.121 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8dfiEkAK3dkH; Thu, 11 Feb 2021 08:26:22 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9652E3A1731; Thu, 11 Feb 2021 08:26:22 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4Dc27d6kyYz6GFdJ; Thu, 11 Feb 2021 08:26:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=2.tigertech; t=1613060781; bh=8xTEDhseDchluTzxLLCSqk+W0YKhNUAhn6KlR0Jxsh8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=hp4oTsIEjdfwCX/VlDHlIfGtKWC+Dq3TWkI9K95BffIW+t6RG2R3blpZa3VivZV/r j99cLhRD9KxHYf2PBMbp+enaDO50xzq6EucvQIpFAVHDEQFi5kwPHKefvNp2uvne7d Bz2JVTnTb3Rn82GSjNzsIXPAXGMuTDtrCqtzwduA=
X-Quarantine-ID: <RnyySv8JyHJ2>
X-Virus-Scanned: Debian amavisd-new at
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4Dc27b6sXPz6G9vb; Thu, 11 Feb 2021 08:26:19 -0800 (PST)
To: Linda Dunbar <>, "" <>, Aijun Wang <>, "Acee Lindem (acee)" <>, Stephane Litkowski <>
Cc: "" <>
References: <>
From: "Joel M. Halpern" <>
Message-ID: <>
Date: Thu, 11 Feb 2021 11:26:18 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
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-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 11 Feb 2021 16:26:24 -0000

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),...

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.


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