Robert, Replies inserted below:
From: Robert Raszuk <[email protected]> Sent: Wednesday, January 19, 2022 10:08 AM To: Linda Dunbar <[email protected]> Cc: Aijun Wang <[email protected]>; Acee Lindem (acee) <[email protected]>; John E Drake <[email protected]>; Les Ginsberg (ginsberg) <[email protected]>; Gyan Mishra <[email protected]>; lsr <[email protected]> Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Linda, > When R3 reduces the aggregated site cost for the prefix A to a specific > topology + > The aggregated site cost only applies to a specific topology. As it has been confirmed with flex-algo authors for a given prefix you can not have different cost per topology. Each locator or prefix can only be associated only with a single topology. That restriction does not apply to SR-MPLS, but I don't think this is what we are discussing here. [Linda] That is why Peter Psenak suggested to use a new Flag in the Flag Algo to indicate the specific topology that needs to consider the Aggregated Site Cost. A New flag (P-flag) is added to indicate that the aggregated site cost needs to be considered for the SPF to the prefix for a specific topology. Flags: 0 1 2 3 4 5 6 7... +-+-+-+-+-+-+-+-+... |M|P| | ... +-+-+-+-+-+-+-+-+... Linda On Wed, Jan 19, 2022 at 4:59 PM Linda Dunbar <[email protected]<mailto:[email protected]>> wrote: Robert, Reply to your comments are inserted below: From: Robert Raszuk <[email protected]<mailto:[email protected]>> Sent: Wednesday, January 19, 2022 4:18 AM To: Linda Dunbar <[email protected]<mailto:[email protected]>> Cc: Aijun Wang <[email protected]<mailto:[email protected]>>; Acee Lindem (acee) <[email protected]<mailto:[email protected]>>; John E Drake <[email protected]<mailto:[email protected]>>; Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>>; Gyan Mishra <[email protected]<mailto:[email protected]>>; lsr <[email protected]<mailto:[email protected]>> Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Hi Linda, The aggregated site cost change rate is comparable with the rate of adding or removing application instances at locations to adapt to the workload distribution changes. [RR] What Les and myself have been trying to highlight here is that the above model does not effectively work well in the underlay layer. The moment you adjust such cost will not really spread workload distribution, but shift it between servers - members of given anycast address. [Linda] that is exactly what the draft is proposing to do: shifting traffic among members of one ANYCAST address. For example, one prefix A has 4 instances attached to 4 different routers (R1/R2/R3/R4). The distance to each of the routers is D1/D2/D3/D4. Routers in 5G Local Data Networks have preconfigured ECMP or (weighted ECMP) to distribute traffic towards A via 4 available paths through R1/R2/R3/R4. When R3 reduces the aggregated site cost for the prefix A to a specific topology (e.g. the specific Local Data Network around Cell tower Cluster X), the shortest path from routers in the Cell Tower Cluster X for the prefix A will be shorter via R3. There are other factors influencing the shortest path computation and ECMP among all paths towards the prefix A. The forwarding decision will happen at the first common P core underlay node from the server side and not the ingress to the network - where is what you would really want. [Linda] The draft is for the scenario where there are multiple common routers towards multiple instances of the same prefix. Linda On Wed, Jan 19, 2022 at 4:52 AM Linda Dunbar <[email protected]<mailto:[email protected]>> wrote: Robert, In the new version of the draft, we have: “The aggregated site cost associated with a prefix (i.e., ANYCAST prefix) can be a value configured on the router to which the prefix is attached. The aggregated site cost can be computed based on an algorithm configured on router for specific prefixes. The detailed algorithm of computing the aggregated site cost is out of the scope of document. As the cost change can impact the path computation, there is a Minimum Interval for Metrics Change Advertisement which is configured on the routers to avoid route oscillations. Default is 30s. The aggregated site cost change rate is comparable with the rate of adding or removing application instances at locations to adapt to the workload distribution changes. The rate of change could be in weeks or days. On rare occasions, there might need rate changes in hours..” Your comments and suggestions are greatly appreciated. Linda From: Robert Raszuk <[email protected]<mailto:[email protected]>> Sent: Monday, January 17, 2022 5:29 AM To: Aijun Wang <[email protected]<mailto:[email protected]>> Cc: Acee Lindem (acee) <[email protected]<mailto:[email protected]>>; Linda Dunbar <[email protected]<mailto:[email protected]>>; John E Drake <[email protected]<mailto:[email protected]>>; Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>>; Gyan Mishra <[email protected]<mailto:[email protected]>>; lsr <[email protected]<mailto:[email protected]>> Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Aijun, Such metric will be same(because of the ANYCAST address be advertised simultaneously via R1/R2/R3 at the same time for one application server, for example, S1/aa08::4450). That is not really correct. On each router R1 or R2 or R3 when you for example redistribute or originate in any other way host route for example S1/aa08::4450 you can apply a different metric to it. That is why I keep asking what is the mechanism in which routers will be informed what host routes to advertise and what metric to use for each IP address of the server or application on the server. The most precise answer received so far was "it is out of scope". And that is important irrespective if we are talking about using passive interfaces, stub interfaces or simply static routes. Thx, R.
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
