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" <[e-mail]>]

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 <[e-mail]>
> Sent: Thursday, February 11, 2021 10:26 AM
> To: Linda Dunbar <[e-mail]>; [e-mail]; Aijun Wang <[e-mail]>; Acee Lindem (acee) <[e-mail]>; Stephane Litkowski <[e-mail]>
> Cc: [e-mail]
> 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://datatracker.ietf.org/doc/draft-dunbar-6man-5g-edge-compute-sticky-service/  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
>> [e-mail]
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
>> ietf.org%2Fmailman%2Flistinfo%2Fidr&amp;data=04%7C01%7Clinda.dunbar%40
>> futurewei.com%7C47fa57e5844749e05e3f08d8cea9c541%7C0fee8ff2a3b240189c7
>> 53a1d5591fedc%7C1%7C0%7C637486575848772996%7CUnknown%7CTWFpbGZsb3d8eyJ
>> WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000
>> &amp;sdata=75pkqbg6z75Ji3MOtZhBdz8wAMrm9FNQg0i7Pwk8IEo%3D&amp;reserved
>> =0
>>