Tony, Thank you very much for the constructive feedback. More questions to your suggestions are inserted below:
Linda From: Tony Li <[email protected]> On Behalf Of Tony Li Sent: Thursday, October 14, 2021 11:28 AM To: Linda Dunbar <[email protected]> Cc: [email protected] Subject: Re: [Lsr] Looking for feedback of using Flex Algo to advertise the 5G edge computing associated metrics Hi Linda, Thank you for your contribution. I have several comments: 1. I think you could abstract this out from 5G and have a much stronger contribution. If I understand correctly, your goal is to route to optimal instances of anycast load balancers. There's nothing radio specific about that. This would also great simplify the discussion. [Linda] The reason of mentioning 5G is because the Local Data Network (LDN) supporting the 5G traffic has some unique characteristics, such as: 1. The routing distance to reach a different Edge Server in LDN is very small. Therefore, there is the need to consider additional metrics for computing the shortest path. 2. When a UE anchors to a new UPF that directly connect to the IP Local Data Network ingress node as the result of anchoring to a new Cell Tower, the source IP address is usually not changed unless the new UPF belongs to a different network operator. The preferred shortest path should point to the Edge Server to which the UE was connected to before the re-anchoring. In 4G, the IP network connected to the 4G's P-GW are far apart, making the routing distance be the major contributor for the Shortest Path. 1. The flow affinity that you request is not something that is normally implemented. The affinity that I'm familiar with is a hash function before indexing into a multi-path table that doesn't fluctuate frequently. I don't think that you have that condition. I could envision some kind of forwarding cache, but that would deserve a careful discussion of cache timeouts, as they need to be consistent across the network. I also don't understand how this would work in the face of a handover. [Linda] The handover in 5G doesn't change source IP addresses. Therefore, the hash method should work, i.e. the packets with the same header fields get indexing to the same egress port. 1. I'm not following how link metrics would interact with your site cost metrics. Do you even want them to? [Linda] The Link Cost mentioned in Section 3.3 is loosely used to indicate the cost reach the attached server, as some servers might be more powerful than others. How about changing the wording to "The cost for the egress edge nodes to reach to their attached servers is embedded in the "capacity index"? 4) I don't think you really want to advertise your site-cost metrics in the FAD. The point of the FAD is to define the constraints for the topology. Yes you will want to use a FAD to advertise that a given algorithm will be using your specific Calc-Type, but I'm not seeing any kind of global topology constraints here. The metrics that you're advertising don't belong in the FAD and instead should probably be in a prefix reachability TLV. [Linda] Can FAD define a topology that excluding some edge servers based on source IP address? For example, when a UE anchors to a new UPF that connects to a new ingress router, the new topology for this specific source IP only includes the previous edge server? while as other UEs (different source IP) to the ingress router has the old topology that include all the edge servers? Regards, Tony On Oct 13, 2021, at 3:50 PM, Linda Dunbar <[email protected]<mailto:[email protected]>> wrote: LSR experts: We have updated the draft to reflect the suggestions from LSR WG to use Flex Algo to advertise the metrics associated with the environment where 5G edge computer servers are running. https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-lsr-5g-edge-compute%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ca74ef00ce42c4db6ced808d98f2f8f9e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637698256727241840%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=eeY4mIV49hS3KLcLzrcoNRVNXozKpRr1ioiLxIXjXVA%3D&reserved=0> In a nutshell, the draft proposes some new values in the Flex Algo Definition Sub-TLV * A new Metric-Type is introduced to indicate the Aggregated Cost AppMetaData Metrics included in computing the constrained SPF. * Additional subsub-TLVs to be included in the Flex Algo Definition Sub-TLV to carry the detailed metrics for the constrained SPF. We are looking for feedback of our revised approach. Thank you. Linda Dunbar _______________________________________________ Lsr mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lsr<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ca74ef00ce42c4db6ced808d98f2f8f9e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637698256727251798%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=veNWHKiNi%2F70da%2FCusMyVFubWfg9nyWvmn50YxVNPCg%3D&reserved=0>
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
