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. So with that what Acee is asking seems very reasonable - to simply use base topology and compute the reachability using combined cost (base + external) to your anycast prefixes. Thx, R. On Wed, Jan 19, 2022 at 4:59 PM Linda Dunbar <[email protected]> wrote: > Robert, > > > > Reply to your comments are inserted below: > > > > *From:* Robert Raszuk <[email protected]> > *Sent:* Wednesday, January 19, 2022 4:18 AM > *To:* Linda Dunbar <[email protected]> > *Cc:* Aijun Wang <[email protected]>; Acee Lindem (acee) <acee= > [email protected]>; John E Drake <jdrake= > [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 > > > > 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]> > 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]> > *Sent:* Monday, January 17, 2022 5:29 AM > *To:* Aijun Wang <[email protected]> > *Cc:* Acee Lindem (acee) <[email protected]>; Linda Dunbar < > [email protected]>; John E Drake <jdrake= > [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 > > > > 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
