Hi Linda, I read your draft draft-dunbar-lsr-5g-edge-compute. >From my understanding you are using various parameters such as capacity index, >preference,network delay etc To derive a metric. You want to use this derived metric for SPF computation.
My suggestion would be to define new standard metric under generic metric called "Edge computing metric". This metric would be similar to "bandwidth metric " defined in draft-ietf-lsr-flex-algo-bw-con. This edge computing metric will be computed based on various advertised parameters (similar to bandwidth metric which is computed based on link-bandwidth). A flex-algo can then be used to compute using metric-type "Edge computing metric". Rgds Shraddha Juniper Business Use Only From: Lsr <[email protected]> On Behalf Of Linda Dunbar Sent: Friday, September 17, 2021 12:58 AM To: Acee Lindem (acee) <[email protected]>; Tony Li <[email protected]>; Peter Psenak (ppsenak) <[email protected]> Cc: [email protected]; [email protected]; Acee Lindem (acee) <[email protected]> Subject: [Lsr] questions about draft-ietf-lsr-flex-algo-bw-con-01 [External Email. Be cautious of content] Shraddha, Bill, Rajesh, Bruno, Peter, and Tony, Is it correct that the intent of the draft is to prevent some "elephant flows" from being placed over certain links? Section 2.1 listed the TLV for the ISIS Generic Metric Is the property of preventing some flows being placed on a link to be encoded in the Value field of the ISIS Generic Metric in Section 2.1? Why not directly included in the value field of Flex Algo TLV? Section 2.3 says that using FAPM sub-TLV to indicate Flex Algo needs to use the Generic Metric. But this property of preventing some flows to be placed on certain links doesn't need to be generic, does it? How does an IGP node know which link to advertise this property? Is it by configuration? Linda Dunbar From: Acee Lindem (acee) <[email protected]<mailto:[email protected]>> Sent: Wednesday, September 15, 2021 4:30 PM To: Linda Dunbar <[email protected]<mailto:[email protected]>>; Tony Li <[email protected]<mailto:[email protected]>>; Peter Psenak (ppsenak) <[email protected]<mailto:[email protected]>> Cc: Acee Lindem (acee) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [Lsr] draft-ietf-lsr-flex-algo Hi Linda, Tony, From: Linda Dunbar <[email protected]<mailto:[email protected]>> Date: Wednesday, September 15, 2021 at 3:45 PM To: Tony Li <[email protected]<mailto:[email protected]>>, "Peter Psenak (ppsenak)" <[email protected]<mailto:[email protected]>> Cc: "Acee Lindem (acee)" <[email protected]<mailto:[email protected]>>, Acee Lindem <[email protected]<mailto:[email protected]>>, Bruno Decraene <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: RE: [Lsr] draft-ietf-lsr-flex-algo Tony, Answers are inserted below: From: Tony Li <[email protected]<mailto:[email protected]>> On Behalf Of Tony Li Sent: Wednesday, September 15, 2021 1:26 PM To: Peter Psenak <[email protected]<mailto:[email protected]>> Cc: Acee Lindem (acee) <[email protected]<mailto:[email protected]>>; Acee Lindem (acee) <[email protected]<mailto:[email protected]>>; Linda Dunbar <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [Lsr] draft-ietf-lsr-flex-algo On Sep 15, 2021, at 11:17 AM, Peter Psenak <[email protected]<mailto:[email protected]>> wrote: So, if someone wants to define new constraints (e.g., Linda's server/application metrics), they would need to define the semantics and encodings similar to what is being done for bandwidth metrics in https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-ietf-lsr-flex-algo-bw-con*2F&data=04*7C01*7Clinda.dunbar*40futurewei.com*7C5b92535cbd7e4501dadd08d978900d0d*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637673382361243040*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=*2Bvy*2FOpJOrTO3zhdZ16p3iNo2yD*2F4LkrJWShiDoU3z7o*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!XpHrOqWnYWMc805FAvf4iN-4Fb7MxNhxNRTQ2p94eWcBZuoBEWo8hTKOJSY-LUDB$> . Then the flex algos could be defined using these metrics. Correct? yes, they would need to define a new FAD constraint and/or metric only. I agree that if the goal is a new metric, then that's sufficient. [Plug for generic metrics.] It sounded a bit like Linda was wanting a fundamental change to the SPF algorithm. If, so, I believe that would require a new Calc-Type. Linda, could you please clarify? [Linda] I don't think so. We want a constrained SPF algorithm that take into additional metrics. Just like TE being added into the SPF. I was thinking that as well. These metrics would be defined to have precedence over the path cost - sort of like OSPF Type 2 external metrics do for OSPF AS External routes. Thanks, Acee Linda Dunbar Tony
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
