Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Hi, Robert: What I want to say is that the proposed “Attributes” is actually “metric” to the prefixes, or attributes of the stub links that connected to the prefix. It is not different from the metric within the IGP core transport. It should be noticed that in your mentioned scenario, all the interface address information about the stub link are already within the IGP if you configure them as “Passive”, or “Stub Link”. The difference is only advertising the interface address(current status), or the interface prefix address(as the attributes of the stub link). And, as we all understand, the mentioned IGP Egress Engineering(for abbreviation, we can call it “IGP-EE”) will only exist for the “ANYCAST” address. Will you spread your “ANYCAST” address on all of the stub links? If not, we need not worry the overwhelming possibilities. And I think what your worry should be considered within the operation deployment, not the protocol itself. For example, all the metrics within the IGP are not static and can be adjusted, but we will adjust them only when necessary. We should also notice that the IGP are considering adding more dynamic metrics to meet the service/network requirement(for example, link delay metric). The IGP should be evolved to have more flexible capabilities to meet various scenarios. The operator will have their considerations or restrictions when deploying these new features. Best Regards Aijun Wang China Telecom From: lsr-boun...@ietf.org On Behalf Of Robert Raszuk Sent: Wednesday, January 19, 2022 10:28 PM To: lsr ; Aijun Wang ; Linda Dunbar Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute All, There is a fundamental question in respect to your and Linda drafts - how much service awareness should be carried by link state protocols. Historically till today IGPs provide stable underlay reachability within the IGP coverage area (including hierarchy). Yes they were extended to carry underlay TE or SR information, but still that was within the core transport. All external or service information where not carried by neither OSPF nor ISIS. Neither was node liveness as an extra indicator. Various services were loaded onto BGP and BGP was and still continues to be the victim of those who think that it is cool to make network service rich and smart. I understand now its IGP turn to overload it with lots of external and in fact opaque to native IGP function stuff. And once we open that gate we will be walking on the cliff where the edge is not rock, but clay or sand. Very honestly I do think that information about services do not belong to link state protocols. They are much better handled at the application layer and in the end to end fashion between actual application endpoints. We should aim to decrease state carried and handled by IGPs not spending time on the absolute reverse. See take your stub link draft ... say an area may have 100 intra-area links and 1000s of external logical links (example VLANs) which you proposed to model as link. Moreover, information advertised with those stub links may be dynamic which multiplied by scale has clear potential to overwhelm (in processing or distribution) by orders of magnitude important data coming with real transport links. Kind regards, Robert On Wed, Jan 19, 2022 at 3:06 PM Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote: Hi, Robert: As described in the draft, “all those locations can be close in proximity. There might be a tiny difference in the routing distance to reach an application instance attached to a different edge router” So, the “aggregated cost” or other factors that associated with the stub link may be more important for selecting the right server. I think it is not important for P router responses or Ingress router responses first. In Figure 10, you will notice the client’s traffic is first distributed via the DNS to different “ANYCAST” address. Then for the same “ANYCAST” address, the client will prefer one of the three server, if these server has different “aggregated cost” We can now adjust the “aggregated cost” to influence the traffic distribution among these three servers for the same “ANYCAST” address. For example, if we set all the”aggregated cost” same for one “ANYCAST” address(for example, aa08:4450), then the traffic to this address will be distributed equally among the three locations. No traffic oscillation will occur. The key point here is that the attributes associated with these stub links/prefixes should be considered or emphasized. Aijun Wang China Telecom On Jan 19, 2022, at 18:19, Robert Raszuk mailto:rob...@raszuk.net> > wrote: 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.
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Hi Linda, From: Linda Dunbar Date: Wednesday, January 19, 2022 at 12:05 PM To: Acee Lindem , Robert Raszuk , Aijun Wang , "muthu.a...@gmail.com" Cc: John E Drake , "Les Ginsberg (ginsberg)" , Gyan Mishra , lsr Subject: RE: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Acee, Thank you for the valid point. The aggregated site cost is supposed to impact a specific topology with a small number of routers, e.g. routers near a cluster of cell towers X. How do you guarantee all the routers in the “topology” use the same algorithm and how does the “topology” relate to an IGP domain. Is it separate? Thanks, Acee We will add some description to the draft to address your points. Thank you. Linda From: Acee Lindem (acee) Sent: Wednesday, January 19, 2022 10:09 AM To: Linda Dunbar ; Robert Raszuk ; Aijun Wang ; muthu.a...@gmail.com Cc: John E Drake ; Les Ginsberg (ginsberg) ; Gyan Mishra ; lsr Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Hi Linda, Thanks for explaining that “aggregated” doesn’t mean that all the previously described application metrics are aggregated but that components each of these metric in the path are aggregated. If the algorithm isn’t specified and not all routers in the IGP domain use the same algorithm, then you have the possibility of loops. Thanks, Acee From: Linda Dunbar mailto:linda.dun...@futurewei.com>> Date: Wednesday, January 19, 2022 at 10:37 AM To: Acee Lindem mailto:a...@cisco.com>>, Robert Raszuk mailto:rob...@raszuk.net>>, Aijun Wang mailto:wangai...@tsinghua.org.cn>>, "muthu.a...@gmail.com<mailto:muthu.a...@gmail.com>" mailto:muthu.a...@gmail.com>> Cc: John E Drake mailto:jdr...@juniper.net>>, "Les Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>>, Gyan Mishra mailto:hayabusa...@gmail.com>>, lsr mailto:lsr@ietf.org>> Subject: RE: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Acee, I am sorry for missing answering your question. Aggregated site cost for a specific prefix is different than the base IGP cost for the following reasons: - The aggregated site cost only applies to a specific topology. The policy is configured to the relevant nodes to take the aggregated site cost into consideration in computing the shortest path. - As Muthu’s email stated that “The metric can be split into 'n' parts all internal to the specific application”. The aggregated site cost can be one value or a set of values. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |AggCostSubTLV | Length| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |AggCost Attribute-1 to the Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ |AggCost Attribute-i to the Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Aggregated cost Advertisement in OSPF Your suggestions and comments are greatly appreciated. Linda Dunbar From: Acee Lindem (acee) mailto:a...@cisco.com>> Sent: Wednesday, January 19, 2022 7:18 AM To: Linda Dunbar mailto:linda.dun...@futurewei.com>>; Robert Raszuk mailto:rob...@raszuk.net>>; Aijun Wang mailto:wangai...@tsinghua.org.cn>> Cc: John E Drake mailto:jdr...@juniper.net>>; Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; Gyan Mishra mailto:hayabusa...@gmail.com>>; lsr mailto:lsr@ietf.org>> Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Hi Linda, You seem to be either missing or avoiding my question as to why the base IGP metric can’t be used now that the draft has a single aggregated cost? Aijun replied with two alternatives for changing it to allow for complex selection algorithm based on multiple metrics. What is the actual requirement here? Acee From: Linda Dunbar mailto:linda.dun...@futurewei.com>> Date: Tuesday, January 18, 2022 at 10:52 PM To: Robert Raszuk mailto:rob...@raszuk.net>>, Aijun Wang mailto:wangai...@tsinghua.org.cn>> Cc: Acee Lindem mailto:a...@cisco.com>>, John E Drake mailto:jdr...@juniper.net>>, "Les Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>>, Gyan Mishra mailto:hayabusa...@gmail.com>>, lsr mailto:lsr@ietf.org>> Subject: RE: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute 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
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Acee, Thank you for the valid point. The aggregated site cost is supposed to impact a specific topology with a small number of routers, e.g. routers near a cluster of cell towers X. We will add some description to the draft to address your points. Thank you. Linda From: Acee Lindem (acee) Sent: Wednesday, January 19, 2022 10:09 AM To: Linda Dunbar ; Robert Raszuk ; Aijun Wang ; muthu.a...@gmail.com Cc: John E Drake ; Les Ginsberg (ginsberg) ; Gyan Mishra ; lsr Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Hi Linda, Thanks for explaining that “aggregated” doesn’t mean that all the previously described application metrics are aggregated but that components each of these metric in the path are aggregated. If the algorithm isn’t specified and not all routers in the IGP domain use the same algorithm, then you have the possibility of loops. Thanks, Acee From: Linda Dunbar mailto:linda.dun...@futurewei.com>> Date: Wednesday, January 19, 2022 at 10:37 AM To: Acee Lindem mailto:a...@cisco.com>>, Robert Raszuk mailto:rob...@raszuk.net>>, Aijun Wang mailto:wangai...@tsinghua.org.cn>>, "muthu.a...@gmail.com<mailto:muthu.a...@gmail.com>" mailto:muthu.a...@gmail.com>> Cc: John E Drake mailto:jdr...@juniper.net>>, "Les Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>>, Gyan Mishra mailto:hayabusa...@gmail.com>>, lsr mailto:lsr@ietf.org>> Subject: RE: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Acee, I am sorry for missing answering your question. Aggregated site cost for a specific prefix is different than the base IGP cost for the following reasons: - The aggregated site cost only applies to a specific topology. The policy is configured to the relevant nodes to take the aggregated site cost into consideration in computing the shortest path. - As Muthu’s email stated that “The metric can be split into 'n' parts all internal to the specific application”. The aggregated site cost can be one value or a set of values. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |AggCostSubTLV | Length| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |AggCost Attribute-1 to the Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ |AggCost Attribute-i to the Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Aggregated cost Advertisement in OSPF Your suggestions and comments are greatly appreciated. Linda Dunbar From: Acee Lindem (acee) mailto:a...@cisco.com>> Sent: Wednesday, January 19, 2022 7:18 AM To: Linda Dunbar mailto:linda.dun...@futurewei.com>>; Robert Raszuk mailto:rob...@raszuk.net>>; Aijun Wang mailto:wangai...@tsinghua.org.cn>> Cc: John E Drake mailto:jdr...@juniper.net>>; Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; Gyan Mishra mailto:hayabusa...@gmail.com>>; lsr mailto:lsr@ietf.org>> Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Hi Linda, You seem to be either missing or avoiding my question as to why the base IGP metric can’t be used now that the draft has a single aggregated cost? Aijun replied with two alternatives for changing it to allow for complex selection algorithm based on multiple metrics. What is the actual requirement here? Acee From: Linda Dunbar mailto:linda.dun...@futurewei.com>> Date: Tuesday, January 18, 2022 at 10:52 PM To: Robert Raszuk mailto:rob...@raszuk.net>>, Aijun Wang mailto:wangai...@tsinghua.org.cn>> Cc: Acee Lindem mailto:a...@cisco.com>>, John E Drake mailto:jdr...@juniper.net>>, "Les Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>>, Gyan Mishra mailto:hayabusa...@gmail.com>>, lsr mailto:lsr@ietf.org>> Subject: RE: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute 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
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Linda, But the point is that you can only have a single topology for a prefix - so why not to do it in base ? Thx On Wed, Jan 19, 2022 at 5:28 PM Linda Dunbar wrote: > Robert, > > > > Replies inserted below: > > > > > > *From:* Robert Raszuk > *Sent:* Wednesday, January 19, 2022 10:08 AM > *To:* Linda Dunbar > *Cc:* Aijun Wang ; Acee Lindem (acee) 40cisco@dmarc.ietf.org>; John E Drake 40juniper@dmarc.ietf.org>; Les Ginsberg (ginsberg) ; > Gyan Mishra ; lsr > *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 > wrote: > > Robert, > > > > Reply to your comments are inserted below: > > > > *From:* Robert Raszuk > *Sent:* Wednesday, January 19, 2022 4:18 AM > *To:* Linda Dunbar > *Cc:* Aijun Wang ; Acee Lindem (acee) 40cisco@dmarc.ietf.org>; John E Drake 40juniper@dmarc.ietf.org>; Les Ginsberg (ginsberg) ; > Gyan Mishra ; lsr > *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 > 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 th
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Robert, Replies inserted below: From: Robert Raszuk Sent: Wednesday, January 19, 2022 10:08 AM To: Linda Dunbar Cc: Aijun Wang ; Acee Lindem (acee) ; John E Drake ; Les Ginsberg (ginsberg) ; Gyan Mishra ; lsr 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 mailto:linda.dun...@futurewei.com>> wrote: Robert, Reply to your comments are inserted below: From: Robert Raszuk mailto:rob...@raszuk.net>> Sent: Wednesday, January 19, 2022 4:18 AM To: Linda Dunbar mailto:linda.dun...@futurewei.com>> Cc: Aijun Wang mailto:wangai...@tsinghua.org.cn>>; Acee Lindem (acee) mailto:40cisco@dmarc.ietf.org>>; John E Drake mailto:40juniper@dmarc.ietf.org>>; Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; Gyan Mishra mailto:hayabusa...@gmail.com>>; lsr mailto:lsr@ietf.org>> 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 mailto:linda.dun...@futurewei.com>> 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 mailto:rob...@raszuk.net>> Sent: Monday, January 17, 2022 5:29 AM To: Aijun Wang mailto:wangai...@tsinghua.org.cn>> Cc: Acee Lindem (acee) mailto:40cisco@dmarc.ietf.org>>; Linda Dunbar mailto:linda.dun...@futurewei.com>>; John E Drake mailto:40juniper@dmarc.ietf.org>>; Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; Gyan Mishra mailto:hayabusa...@gmail.com>>; lsr mailto:lsr@ietf.org>> Subject: Re: [Lsr] Seeking feedback to the rev
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Hi Linda, Thanks for explaining that “aggregated” doesn’t mean that all the previously described application metrics are aggregated but that components each of these metric in the path are aggregated. If the algorithm isn’t specified and not all routers in the IGP domain use the same algorithm, then you have the possibility of loops. Thanks, Acee From: Linda Dunbar Date: Wednesday, January 19, 2022 at 10:37 AM To: Acee Lindem , Robert Raszuk , Aijun Wang , "muthu.a...@gmail.com" Cc: John E Drake , "Les Ginsberg (ginsberg)" , Gyan Mishra , lsr Subject: RE: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Acee, I am sorry for missing answering your question. Aggregated site cost for a specific prefix is different than the base IGP cost for the following reasons: - The aggregated site cost only applies to a specific topology. The policy is configured to the relevant nodes to take the aggregated site cost into consideration in computing the shortest path. - As Muthu’s email stated that “The metric can be split into 'n' parts all internal to the specific application”. The aggregated site cost can be one value or a set of values. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |AggCostSubTLV | Length| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |AggCost Attribute-1 to the Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ |AggCost Attribute-i to the Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Aggregated cost Advertisement in OSPF Your suggestions and comments are greatly appreciated. Linda Dunbar From: Acee Lindem (acee) Sent: Wednesday, January 19, 2022 7:18 AM To: Linda Dunbar ; Robert Raszuk ; Aijun Wang Cc: John E Drake ; Les Ginsberg (ginsberg) ; Gyan Mishra ; lsr Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Hi Linda, You seem to be either missing or avoiding my question as to why the base IGP metric can’t be used now that the draft has a single aggregated cost? Aijun replied with two alternatives for changing it to allow for complex selection algorithm based on multiple metrics. What is the actual requirement here? Acee From: Linda Dunbar mailto:linda.dun...@futurewei.com>> Date: Tuesday, January 18, 2022 at 10:52 PM To: Robert Raszuk mailto:rob...@raszuk.net>>, Aijun Wang mailto:wangai...@tsinghua.org.cn>> Cc: Acee Lindem mailto:a...@cisco.com>>, John E Drake mailto:jdr...@juniper.net>>, "Les Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>>, Gyan Mishra mailto:hayabusa...@gmail.com>>, lsr mailto:lsr@ietf.org>> Subject: RE: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute 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 mailto:rob...@raszuk.net>> Sent: Monday, January 17, 2022 5:29 AM To: Aijun Wang mailto:wangai...@tsinghua.org.cn>> Cc: Acee Lindem (acee) mailto:acee=40cisco@dmarc.ietf.org>>; Linda Dunbar mailto:linda.dun...@futurewei.com>>; John E Drake mailto:jdrake=40juniper@dmarc.ietf.org>>; Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; Gyan Mishra mailto:hayabusa...@gmail.com>>; lsr mailto:lsr@ietf.org>> 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 w
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. 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 wrote: > Robert, > > > > Reply to your comments are inserted below: > > > > *From:* Robert Raszuk > *Sent:* Wednesday, January 19, 2022 4:18 AM > *To:* Linda Dunbar > *Cc:* Aijun Wang ; Acee Lindem (acee) 40cisco@dmarc.ietf.org>; John E Drake 40juniper@dmarc.ietf.org>; Les Ginsberg (ginsberg) ; > Gyan Mishra ; lsr > *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 > 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 > *Sent:* Monday, January 17, 2022 5:29 AM > *To:* Aijun Wang > *Cc:* Acee Lindem (acee) ; Linda Dunbar < > linda.dun...@futurewei.com>; John E Drake 40juniper@dmarc.ietf.org>; Les Ginsberg (ginsberg) ; > Gyan Mishra ; lsr > *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 > a
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Robert, Reply to your comments are inserted below: From: Robert Raszuk Sent: Wednesday, January 19, 2022 4:18 AM To: Linda Dunbar Cc: Aijun Wang ; Acee Lindem (acee) ; John E Drake ; Les Ginsberg (ginsberg) ; Gyan Mishra ; lsr 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 mailto:linda.dun...@futurewei.com>> 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 mailto:rob...@raszuk.net>> Sent: Monday, January 17, 2022 5:29 AM To: Aijun Wang mailto:wangai...@tsinghua.org.cn>> Cc: Acee Lindem (acee) mailto:40cisco@dmarc.ietf.org>>; Linda Dunbar mailto:linda.dun...@futurewei.com>>; John E Drake mailto:40juniper@dmarc.ietf.org>>; Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; Gyan Mishra mailto:hayabusa...@gmail.com>>; lsr mailto:lsr@ietf.org>> 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Acee, I am sorry for missing answering your question. Aggregated site cost for a specific prefix is different than the base IGP cost for the following reasons: * The aggregated site cost only applies to a specific topology. The policy is configured to the relevant nodes to take the aggregated site cost into consideration in computing the shortest path. * As Muthu’s email stated that “The metric can be split into 'n' parts all internal to the specific application”. The aggregated site cost can be one value or a set of values. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |AggCostSubTLV | Length| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |AggCost Attribute-1 to the Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ |AggCost Attribute-i to the Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Aggregated cost Advertisement in OSPF Your suggestions and comments are greatly appreciated. Linda Dunbar From: Acee Lindem (acee) Sent: Wednesday, January 19, 2022 7:18 AM To: Linda Dunbar ; Robert Raszuk ; Aijun Wang Cc: John E Drake ; Les Ginsberg (ginsberg) ; Gyan Mishra ; lsr Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Hi Linda, You seem to be either missing or avoiding my question as to why the base IGP metric can’t be used now that the draft has a single aggregated cost? Aijun replied with two alternatives for changing it to allow for complex selection algorithm based on multiple metrics. What is the actual requirement here? Acee From: Linda Dunbar mailto:linda.dun...@futurewei.com>> Date: Tuesday, January 18, 2022 at 10:52 PM To: Robert Raszuk mailto:rob...@raszuk.net>>, Aijun Wang mailto:wangai...@tsinghua.org.cn>> Cc: Acee Lindem mailto:a...@cisco.com>>, John E Drake mailto:jdr...@juniper.net>>, "Les Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>>, Gyan Mishra mailto:hayabusa...@gmail.com>>, lsr mailto:lsr@ietf.org>> Subject: RE: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute 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 mailto:rob...@raszuk.net>> Sent: Monday, January 17, 2022 5:29 AM To: Aijun Wang mailto:wangai...@tsinghua.org.cn>> Cc: Acee Lindem (acee) mailto:acee=40cisco@dmarc.ietf.org>>; Linda Dunbar mailto:linda.dun...@futurewei.com>>; John E Drake mailto:jdrake=40juniper@dmarc.ietf.org>>; Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; Gyan Mishra mailto:hayabusa...@gmail.com>>; lsr mailto:lsr@ietf.org>> 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Hi, Just curious, keeping the 5G use case and applications aside, is it fair to consider the new metric analogous to TE metric for a prefix that CSPF can use? The metric can be split into 'n' parts all internal to the specific application? Regards, Muthu On Wed, Jan 19, 2022 at 7:36 PM Aijun Wang wrote: > Hi, Robert: > > As described in the draft, “all those locations can be close in proximity. > There might be a tiny difference in the routing distance to reach an > application instance attached to a different edge router” > So, the “aggregated cost” or other factors that associated with the stub > link may be more important for selecting the right server. > I think it is not important for P router responses or Ingress router > responses first. In Figure 10, you will notice the client’s traffic is > first distributed via the DNS to different “ANYCAST” address. Then for the > same “ANYCAST” address, the client will prefer one of the three server, if > these server has different “aggregated cost” > We can now adjust the “aggregated cost” to influence the traffic > distribution among these three servers for the same “ANYCAST” address. > For example, if we set all the”aggregated cost” same for one “ANYCAST” > address(for example, aa08:4450), then the traffic to this address will be > distributed equally among the three locations. No traffic oscillation will > occur. > > The key point here is that the attributes associated with these stub > links/prefixes should be considered or emphasized. > > > Aijun Wang > China Telecom > > On Jan 19, 2022, at 18:19, Robert Raszuk wrote: > > > 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. 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. > > Only in very specific topologies you may see some more control, but I > would say that this is rather an exception then a rule. > > Thx, > R. > > > > On Wed, Jan 19, 2022 at 4:52 AM Linda Dunbar > 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 >> *Sent:* Monday, January 17, 2022 5:29 AM >> *To:* Aijun Wang >> *Cc:* Acee Lindem (acee) ; Linda Dunbar >> ; John E Drake > 40juniper@dmarc.ietf.org>; Les Ginsberg (ginsberg) < >> ginsb...@cisco.com>; Gyan Mishra ; lsr < >> lsr@ietf.org> >> *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 rou
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
All, There is a fundamental question in respect to your and Linda drafts - how much service awareness should be carried by link state protocols. Historically till today IGPs provide stable underlay reachability within the IGP coverage area (including hierarchy). Yes they were extended to carry underlay TE or SR information, but still that was within the core transport. All external or service information where not carried by neither OSPF nor ISIS. Neither was node liveness as an extra indicator. Various services were loaded onto BGP and BGP was and still continues to be the victim of those who think that it is cool to make network service rich and smart. I understand now its IGP turn to overload it with lots of external and in fact opaque to native IGP function stuff. And once we open that gate we will be walking on the cliff where the edge is not rock, but clay or sand. Very honestly I do think that information about services do not belong to link state protocols. They are much better handled at the application layer and in the end to end fashion between actual application endpoints. We should aim to decrease state carried and handled by IGPs not spending time on the absolute reverse. See take your stub link draft ... say an area may have 100 intra-area links and 1000s of external logical links (example VLANs) which you proposed to model as link. Moreover, information advertised with those stub links may be dynamic which multiplied by scale has clear potential to overwhelm (in processing or distribution) by orders of magnitude important data coming with real transport links. Kind regards, Robert On Wed, Jan 19, 2022 at 3:06 PM Aijun Wang wrote: > Hi, Robert: > > As described in the draft, “all those locations can be close in proximity. > There might be a tiny difference in the routing distance to reach an > application instance attached to a different edge router” > So, the “aggregated cost” or other factors that associated with the stub > link may be more important for selecting the right server. > I think it is not important for P router responses or Ingress router > responses first. In Figure 10, you will notice the client’s traffic is > first distributed via the DNS to different “ANYCAST” address. Then for the > same “ANYCAST” address, the client will prefer one of the three server, if > these server has different “aggregated cost” > We can now adjust the “aggregated cost” to influence the traffic > distribution among these three servers for the same “ANYCAST” address. > For example, if we set all the”aggregated cost” same for one “ANYCAST” > address(for example, aa08:4450), then the traffic to this address will be > distributed equally among the three locations. No traffic oscillation will > occur. > > The key point here is that the attributes associated with these stub > links/prefixes should be considered or emphasized. > > Aijun Wang > China Telecom > > On Jan 19, 2022, at 18:19, Robert Raszuk wrote: > > > 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. 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. > > Only in very specific topologies you may see some more control, but I > would say that this is rather an exception then a rule. > > Thx, > R. > > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Hi, Robert: As described in the draft, “all those locations can be close in proximity. There might be a tiny difference in the routing distance to reach an application instance attached to a different edge router” So, the “aggregated cost” or other factors that associated with the stub link may be more important for selecting the right server. I think it is not important for P router responses or Ingress router responses first. In Figure 10, you will notice the client’s traffic is first distributed via the DNS to different “ANYCAST” address. Then for the same “ANYCAST” address, the client will prefer one of the three server, if these server has different “aggregated cost” We can now adjust the “aggregated cost” to influence the traffic distribution among these three servers for the same “ANYCAST” address. For example, if we set all the”aggregated cost” same for one “ANYCAST” address(for example, aa08:4450), then the traffic to this address will be distributed equally among the three locations. No traffic oscillation will occur. The key point here is that the attributes associated with these stub links/prefixes should be considered or emphasized. Aijun Wang China Telecom > On Jan 19, 2022, at 18:19, Robert Raszuk wrote: > > > 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. 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. > > Only in very specific topologies you may see some more control, but I would > say that this is rather an exception then a rule. > > Thx, > R. > > > >> On Wed, Jan 19, 2022 at 4:52 AM Linda Dunbar >> 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 >> Sent: Monday, January 17, 2022 5:29 AM >> To: Aijun Wang >> Cc: Acee Lindem (acee) ; Linda Dunbar >> ; John E Drake >> ; Les Ginsberg (ginsberg) >> ; Gyan Mishra ; lsr >> 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 > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Hi Linda, You seem to be either missing or avoiding my question as to why the base IGP metric can’t be used now that the draft has a single aggregated cost? Aijun replied with two alternatives for changing it to allow for complex selection algorithm based on multiple metrics. What is the actual requirement here? Acee From: Linda Dunbar Date: Tuesday, January 18, 2022 at 10:52 PM To: Robert Raszuk , Aijun Wang Cc: Acee Lindem , John E Drake , "Les Ginsberg (ginsberg)" , Gyan Mishra , lsr Subject: RE: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute 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 Sent: Monday, January 17, 2022 5:29 AM To: Aijun Wang Cc: Acee Lindem (acee) ; Linda Dunbar ; John E Drake ; Les Ginsberg (ginsberg) ; Gyan Mishra ; lsr 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
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. 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. Only in very specific topologies you may see some more control, but I would say that this is rather an exception then a rule. Thx, R. On Wed, Jan 19, 2022 at 4:52 AM Linda Dunbar 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 > *Sent:* Monday, January 17, 2022 5:29 AM > *To:* Aijun Wang > *Cc:* Acee Lindem (acee) ; Linda Dunbar < > linda.dun...@futurewei.com>; John E Drake 40juniper....@dmarc.ietf.org>; Les Ginsberg (ginsberg) ; > Gyan Mishra ; lsr > *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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
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 Sent: Monday, January 17, 2022 5:29 AM To: Aijun Wang Cc: Acee Lindem (acee) ; Linda Dunbar ; John E Drake ; Les Ginsberg (ginsberg) ; Gyan Mishra ; lsr 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Hi, Acee: Actually I think so. We would like to hear more comments for the two approaches. It’s better to update the draft based on the consensus or through discussion. Aijun Wang China Telecom > On Jan 17, 2022, at 21:15, Acee Lindem (acee) > wrote: > > > Hi Aijung, > So I guess you’re saying the current draft with a single aggregated cost is > incorrect and will be updated? > Thanks, > Acee > > From: Aijun Wang > Date: Sunday, January 16, 2022 at 9:47 PM > To: Acee Lindem , 'Linda Dunbar' > , John E Drake > Cc: "Les Ginsberg (ginsberg)" , 'Gyan Mishra' > , Robert Raszuk , "lsr@ietf.org" > > Subject: RE: [Lsr] Seeking feedback to the revised > draft-dunbar-lsr-5g-edge-compute > > Hi, Acee: > > My thought is that the traditional IGP metric is the cost from ingress > routers(Ra/Rb) to egress routers(R1/R2/R3) which is illustrated in > https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-04#appendix-A. > 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). > > But, In the above mentioned scenario, there are other factors to be > considered, or other factors may be more signification for the selection of > ANYCAST server, for example, the Capacity Index, the Preference Index and > other constraints. > The egress router(A-ER) now calculate the aggregated metric based on these > factors. The derived cost should be considered or added at the IGP SPF > calculation to the ANYCAST prefix. > > There are two way to advertise such additional information: > 1) To define another type prefix cost, and also the new Flexalgo > algorithm, to indicate that both the traditional prefix metric and this > additional aggregated metric should be considered together to select the > right egress router > 2) To put the additional cost information within the Stub-Link TLV that > defined in > https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-03, > > > Both can results in the EPE(Egress Peering Engineering)-like effect. > But I am prefer to the second option, because in such scenario, the stub link > bandwidth, stub link delay etc factors should also be considered when to > select the best egress, they are not the attribute of prefixes. > > We should also know that for these “no inter-as boundary link”, or ‘stub > link’, the associated prefix will not be advertised into the IGP > automatically, only the local interface address of the stub link on the > egress router will be advertised. > > Best Regards > > Aijun Wang > China Telecom > > From: lsr-boun...@ietf.org On Behalf Of Acee Lindem > (acee) > Sent: Sunday, January 16, 2022 10:42 PM > To: Linda Dunbar ; Aijun Wang > ; John E Drake > > Cc: Les Ginsberg (ginsberg) ; Gyan Mishra > ; Robert Raszuk ; lsr@ietf.org > Subject: Re: [Lsr] Seeking feedback to the revised > draft-dunbar-lsr-5g-edge-compute > > Hi Linda, > > I guess you misunderstood me. Since the only advertises a single aggregated > metric, you don’t need a new aggregated cost TLV or to use flex algorithm. > Just set the base IGP metric for the prefix to the aggregated metric and IGPs > will route based on that metric. > > Thanks, > Acee > > From: Linda Dunbar > Date: Saturday, January 15, 2022 at 8:03 PM > To: Acee Lindem , Aijun Wang , > John E Drake > Cc: "Les Ginsberg (ginsberg)" , Gyan Mishra > , Robert Raszuk , "lsr@ietf.org" > > Subject: RE: [Lsr] Seeking feedback to the revised > draft-dunbar-lsr-5g-edge-compute > > Acee, John, Robert, and LSR experts: > > We have updated the draft to reflect the comments and suggestions on the LSR > mailing list. > https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute/ > > In particular: > > - This draft describes using additional site costs to influence the > shortest path computation for a specific set of prefixes. As there are a > small number of egress routers having those prefixes (or destinations) that > need to incorporate site costs in SPF computation, Flexible Algorithms > [LSR-FlexAlgo] is used to indicate the need for the site costs to be > considered for the specific topologies. > > Need a Flag in the Flexible Algorithm TLV to indicate that “site-cost” needs > to be included for the constrained SPF to reach the Prefix. > Therefore, it is not informational draft. > > The “Site Cost” associated with a prefix (i.e., ANYCAST prefix) can be a > value configured on the router to which the pref
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Hi, Robert: I think redistribute the route with the additional cost is possible but we should consider the aggregated cost may changed upon the server status, although not very frequently or in one controllable manner. The aggregated cost is measured and calculated at the egress router. It’s behavior is similar with the link delay attributes. Aijun Wang China Telecom > On Jan 17, 2022, at 19:29, Robert Raszuk wrote: > > > 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Hi, Acee: My thought is that the traditional IGP metric is the cost from ingress routers(Ra/Rb) to egress routers(R1/R2/R3) which is illustrated in https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-04#appendix-A. 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). But, In the above mentioned scenario, there are other factors to be considered, or other factors may be more signification for the selection of ANYCAST server, for example, the Capacity Index, the Preference Index and other constraints. The egress router(A-ER) now calculate the aggregated metric based on these factors. The derived cost should be considered or added at the IGP SPF calculation to the ANYCAST prefix. There are two way to advertise such additional information: 1) To define another type prefix cost, and also the new Flexalgo algorithm, to indicate that both the traditional prefix metric and this additional aggregated metric should be considered together to select the right egress router 2) To put the additional cost information within the Stub-Link TLV that defined in https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-03, Both can results in the EPE(Egress Peering Engineering)-like effect. But I am prefer to the second option, because in such scenario, the stub link bandwidth, stub link delay etc factors should also be considered when to select the best egress, they are not the attribute of prefixes. We should also know that for these “no inter-as boundary link”, or ‘stub link’, the associated prefix will not be advertised into the IGP automatically, only the local interface address of the stub link on the egress router will be advertised. Best Regards Aijun Wang China Telecom From: lsr-boun...@ietf.org On Behalf Of Acee Lindem (acee) Sent: Sunday, January 16, 2022 10:42 PM To: Linda Dunbar ; Aijun Wang ; John E Drake Cc: Les Ginsberg (ginsberg) ; Gyan Mishra ; Robert Raszuk ; lsr@ietf.org Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Hi Linda, I guess you misunderstood me. Since the only advertises a single aggregated metric, you don’t need a new aggregated cost TLV or to use flex algorithm. Just set the base IGP metric for the prefix to the aggregated metric and IGPs will route based on that metric. Thanks, Acee From: Linda Dunbar mailto:linda.dun...@futurewei.com> > Date: Saturday, January 15, 2022 at 8:03 PM To: Acee Lindem mailto:a...@cisco.com> >, Aijun Wang mailto:wangai...@tsinghua.org.cn> >, John E Drake mailto:jdrake=40juniper@dmarc.ietf.org> > Cc: "Les Ginsberg (ginsberg)" mailto:ginsb...@cisco.com> >, Gyan Mishra mailto:hayabusa...@gmail.com> >, Robert Raszuk mailto:rob...@raszuk.net> >, "lsr@ietf.org <mailto:lsr@ietf.org> " mailto:lsr@ietf.org> > Subject: RE: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Acee, John, Robert, and LSR experts: We have updated the draft to reflect the comments and suggestions on the LSR mailing list. https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute/ In particular: - This draft describes using additional site costs to influence the shortest path computation for a specific set of prefixes. As there are a small number of egress routers having those prefixes (or destinations) that need to incorporate site costs in SPF computation, Flexible Algorithms [LSR-FlexAlgo] is used to indicate the need for the site costs to be considered for the specific topologies. Need a Flag in the Flexible Algorithm TLV to indicate that “site-cost” needs to be included for the constrained SPF to reach the Prefix. Therefore, it is not informational draft. The “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 actual mechanism of assigning “Site Cost” or the detailed algorithm is out of the scope of document The “site cost” change rate is comparable with the rate that the application controller adds or removes the application instances at locations to adjust the workload distribution. Typically, the rate of change could be in days. On rare occasions, there might need rate changes in hours. We have added a section to emphasize that It is important that the “site cost” metric doesn’t change too frequently to avoid route oscillation within the network. Thank you. Linda From: Acee Lindem (acee) mailto:a...@cisco.com> > Sent: Saturday, January 15, 2022 5:30 AM To: Aijun Wang mailto:wangai...@tsinghua.org.cn> >; John E Drake mailto:jdrake=40juniper@dmarc.ietf.org> > Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com> &
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Hi Linda, I guess you misunderstood me. Since the only advertises a single aggregated metric, you don’t need a new aggregated cost TLV or to use flex algorithm. Just set the base IGP metric for the prefix to the aggregated metric and IGPs will route based on that metric. Thanks, Acee From: Linda Dunbar Date: Saturday, January 15, 2022 at 8:03 PM To: Acee Lindem , Aijun Wang , John E Drake Cc: "Les Ginsberg (ginsberg)" , Gyan Mishra , Robert Raszuk , "lsr@ietf.org" Subject: RE: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Acee, John, Robert, and LSR experts: We have updated the draft to reflect the comments and suggestions on the LSR mailing list. https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute/ In particular: - This draft describes using additional site costs to influence the shortest path computation for a specific set of prefixes. As there are a small number of egress routers having those prefixes (or destinations) that need to incorporate site costs in SPF computation, Flexible Algorithms [LSR-FlexAlgo] is used to indicate the need for the site costs to be considered for the specific topologies. Need a Flag in the Flexible Algorithm TLV to indicate that “site-cost” needs to be included for the constrained SPF to reach the Prefix. Therefore, it is not informational draft. The “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 actual mechanism of assigning “Site Cost” or the detailed algorithm is out of the scope of document The “site cost” change rate is comparable with the rate that the application controller adds or removes the application instances at locations to adjust the workload distribution. Typically, the rate of change could be in days. On rare occasions, there might need rate changes in hours. We have added a section to emphasize that It is important that the “site cost” metric doesn’t change too frequently to avoid route oscillation within the network. Thank you. Linda From: Acee Lindem (acee) Sent: Saturday, January 15, 2022 5:30 AM To: Aijun Wang ; John E Drake Cc: Les Ginsberg (ginsberg) ; Linda Dunbar ; Gyan Mishra ; Robert Raszuk ; lsr@ietf.org Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Hi Aijun, Linda, Independent of the ongoing debate on whether advertising the server metrics in the IGPs… Now that the draft is simplified to use a single aggregated metric, why not make the draft informational and use the base IGP metrics? This avoid the burden of adding a new flex algorithm. Thanks, Acee From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Aijun Wang mailto:wangai...@tsinghua.org.cn>> Date: Friday, January 14, 2022 at 10:38 PM To: John E Drake mailto:jdrake=40juniper@dmarc.ietf.org>> Cc: "Les Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>>, Linda Dunbar mailto:linda.dun...@futurewei.com>>, Gyan Mishra mailto:hayabusa...@gmail.com>>, Robert Raszuk mailto:rob...@raszuk.net>>, "lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>> Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute This draft is now proposing one aggregate cost of the application server. The detailed factors can also be included if necessary. But the principle for advertising them should be controllable, as required by other dynamic metrics in IGP. Aijun Wang China Telecom On Jan 15, 2022, at 08:37, John E Drake mailto:jdrake=40juniper@dmarc.ietf.org>> wrote: This is similar to the issue with the Down/Up proposal. A single metric tells an ingress node nothing about the performance of or load on the individual applications at a given site. Yours Irrespectively, John Juniper Business Use Only From: Aijun Wang mailto:wangai...@tsinghua.org.cn>> Sent: Friday, January 14, 2022 6:58 PM To: John E Drake mailto:jdr...@juniper.net>> Cc: Robert Raszuk mailto:rob...@raszuk.net>>; Gyan Mishra mailto:hayabusa...@gmail.com>>; Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; Linda Dunbar mailto:linda.dun...@futurewei.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute [External Email. Be cautious of content] Hi, John: Here I would also like to hear your own opinions. If not, please see my responses for both you and Robert: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con-01<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lsr-flex-algo-bw-con-01__%3B!!NEt6yMaO-gk!Ruow7KbUPIX1YVq2nIggRiIumNPiEf58LStjoh_L_UpLze1a2LwUW21ecs19GHc%24=04
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Acee, John, Robert, and LSR experts: We have updated the draft to reflect the comments and suggestions on the LSR mailing list. https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute/ In particular: * This draft describes using additional site costs to influence the shortest path computation for a specific set of prefixes. As there are a small number of egress routers having those prefixes (or destinations) that need to incorporate site costs in SPF computation, Flexible Algorithms [LSR-FlexAlgo] is used to indicate the need for the site costs to be considered for the specific topologies. Need a Flag in the Flexible Algorithm TLV to indicate that "site-cost" needs to be included for the constrained SPF to reach the Prefix. Therefore, it is not informational draft. The "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 actual mechanism of assigning "Site Cost" or the detailed algorithm is out of the scope of document The "site cost" change rate is comparable with the rate that the application controller adds or removes the application instances at locations to adjust the workload distribution. Typically, the rate of change could be in days. On rare occasions, there might need rate changes in hours. We have added a section to emphasize that It is important that the "site cost" metric doesn't change too frequently to avoid route oscillation within the network. Thank you. Linda From: Acee Lindem (acee) Sent: Saturday, January 15, 2022 5:30 AM To: Aijun Wang ; John E Drake Cc: Les Ginsberg (ginsberg) ; Linda Dunbar ; Gyan Mishra ; Robert Raszuk ; lsr@ietf.org Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Hi Aijun, Linda, Independent of the ongoing debate on whether advertising the server metrics in the IGPs... Now that the draft is simplified to use a single aggregated metric, why not make the draft informational and use the base IGP metrics? This avoid the burden of adding a new flex algorithm. Thanks, Acee From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Aijun Wang mailto:wangai...@tsinghua.org.cn>> Date: Friday, January 14, 2022 at 10:38 PM To: John E Drake mailto:jdrake=40juniper@dmarc.ietf.org>> Cc: "Les Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>>, Linda Dunbar mailto:linda.dun...@futurewei.com>>, Gyan Mishra mailto:hayabusa...@gmail.com>>, Robert Raszuk mailto:rob...@raszuk.net>>, "lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>> Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute This draft is now proposing one aggregate cost of the application server. The detailed factors can also be included if necessary. But the principle for advertising them should be controllable, as required by other dynamic metrics in IGP. Aijun Wang China Telecom On Jan 15, 2022, at 08:37, John E Drake mailto:jdrake=40juniper@dmarc.ietf.org>> wrote: This is similar to the issue with the Down/Up proposal. A single metric tells an ingress node nothing about the performance of or load on the individual applications at a given site. Yours Irrespectively, John Juniper Business Use Only From: Aijun Wang mailto:wangai...@tsinghua.org.cn>> Sent: Friday, January 14, 2022 6:58 PM To: John E Drake mailto:jdr...@juniper.net>> Cc: Robert Raszuk mailto:rob...@raszuk.net>>; Gyan Mishra mailto:hayabusa...@gmail.com>>; Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; Linda Dunbar mailto:linda.dun...@futurewei.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute [External Email. Be cautious of content] Hi, John: Here I would also like to hear your own opinions. If not, please see my responses for both you and Robert: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con-01<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lsr-flex-algo-bw-con-01__%3B!!NEt6yMaO-gk!Ruow7KbUPIX1YVq2nIggRiIumNPiEf58LStjoh_L_UpLze1a2LwUW21ecs19GHc%24=04%7C01%7Clinda.dunbar%40futurewei.com%7C5ed0b71fabcb42630bdf08d9d81a6858%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637778430231799294%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=TVa27j%2Br9AIn3eD6puZdGPnTSDSqmlEOQ0NQUO0%2FGfc%3D=0> has introduced the "delay metric" into the IGP. Such metric may be variant in every link within the IGP. The proposal in draft-dunbar-lsr-5g-edge-compute is only for the stub-link's/prefixes characteristics, it is the aggregate cost to the server that measured from the router. All the fa
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Hi Aijun, Linda, Independent of the ongoing debate on whether advertising the server metrics in the IGPs… Now that the draft is simplified to use a single aggregated metric, why not make the draft informational and use the base IGP metrics? This avoid the burden of adding a new flex algorithm. Thanks, Acee From: Lsr on behalf of Aijun Wang Date: Friday, January 14, 2022 at 10:38 PM To: John E Drake Cc: "Les Ginsberg (ginsberg)" , Linda Dunbar , Gyan Mishra , Robert Raszuk , "lsr@ietf.org" Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute This draft is now proposing one aggregate cost of the application server. The detailed factors can also be included if necessary. But the principle for advertising them should be controllable, as required by other dynamic metrics in IGP. Aijun Wang China Telecom On Jan 15, 2022, at 08:37, John E Drake wrote: This is similar to the issue with the Down/Up proposal. A single metric tells an ingress node nothing about the performance of or load on the individual applications at a given site. Yours Irrespectively, John Juniper Business Use Only From: Aijun Wang Sent: Friday, January 14, 2022 6:58 PM To: John E Drake Cc: Robert Raszuk ; Gyan Mishra ; Les Ginsberg (ginsberg) ; Linda Dunbar ; lsr@ietf.org Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute [External Email. Be cautious of content] Hi, John: Here I would also like to hear your own opinions. If not, please see my responses for both you and Robert: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con-01<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con-01__;!!NEt6yMaO-gk!Ruow7KbUPIX1YVq2nIggRiIumNPiEf58LStjoh_L_UpLze1a2LwUW21ecs19GHc$> has introduced the “delay metric” into the IGP. Such metric may be variant in every link within the IGP. The proposal in draft-dunbar-lsr-5g-edge-compute is only for the stub-link’s/prefixes characteristics, it is the aggregate cost to the server that measured from the router. All the factors that mentioned by Robert maybe the parameters that influences the performance of the server, which will be reflected in the aggregate cost. Then, the conclusion is that IGP has now the capabilities to deal with the dynamics value(the change frequencies can certainly be controlled, thinking how we control the flapping interface)within the network , the aggregate cost or other quasi-static factor to the server at the edge of the network can also be considered together. Such approaches can certainly let the IGP give more optimal behavior to forward the traffic to the appropriate destination, or follow an optimal path. Aijun Wang China Telecom On Jan 14, 2022, at 23:49, John E Drake mailto:jdrake=40juniper@dmarc.ietf.org>> wrote: Robert is correct on all points. Yours Irrespectively, John Juniper Business Use Only From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Robert Raszuk Sent: Friday, January 14, 2022 4:20 AM To: Gyan Mishra mailto:hayabusa...@gmail.com>> Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; Linda Dunbar mailto:linda.dun...@futurewei.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute [External Email. Be cautious of content] Gyan, This is not a network discussion. There are well proven techniques to direct user sessions or user requests to a pool of servers deployed and operational. All provide robust services. Network plays very little to no role in that. There are also lot's of factors involved in making that decision (CPU load, RAM, Storage, IO, CPU Temp etc ...) and IMO it would be very bad to now make IGP to carry it and make routing decisions (even if separate topology) based on that information. I do not see this like a move into the right direction. That is my input. Kind regards, Robert. On Fri, Jan 14, 2022 at 4:53 AM Gyan Mishra mailto:hayabusa...@gmail.com>> wrote: Robert Responses in-line On Thu, Jan 13, 2022 at 5:55 AM Robert Raszuk mailto:rob...@raszuk.net>> wrote: Gyan, I see what the draft is trying to do now. /* I did not even consider this for the reason described below. */ But what you wrote requires little correction: "So now the server you are on gets overloaded and a site cost gets advertised in the IGP at which point the connection receives a TCP reset" if you s/connection/all connections/ then you quickly realize that what is proposed here is a disaster. Gyan> Remember this is Anycast proximity based routing along with ECMP / UCMP flow based load balancing and most vendors modern routers support some sort of x-tuple ECMP/UCMP hash so the flows would be evenly distributed, so if you have 10s of 100s of paths, the flows would be evenly distributed across all
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Many Thanks for the feedback! Gyan On Fri, Jan 14, 2022 at 10:48 AM John E Drake wrote: > Robert is correct on all points. > > > > Yours Irrespectively, > > > > John > > > > > > Juniper Business Use Only > > *From:* Lsr *On Behalf Of * Robert Raszuk > *Sent:* Friday, January 14, 2022 4:20 AM > *To:* Gyan Mishra > *Cc:* Les Ginsberg (ginsberg) ; Linda Dunbar < > linda.dun...@futurewei.com>; lsr@ietf.org > *Subject:* Re: [Lsr] Seeking feedback to the revised > draft-dunbar-lsr-5g-edge-compute > > > > *[External Email. Be cautious of content]* > > > > Gyan, > > > > This is not a network discussion. There are well proven techniques to > direct user sessions or user requests to a pool of servers deployed and > operational. All provide robust services. Network plays very little to no > role in that. > > > > There are also lot's of factors involved in making that decision (CPU > load, RAM, Storage, IO, CPU Temp etc ...) and IMO it would be very bad to > now make IGP to carry it and make routing decisions (even if separate > topology) based on that information. > > > > I do not see this like a move into the right direction. That is my input. > > > > Kind regards, > > Robert. > > > > > > > > > > > > > > > > > > On Fri, Jan 14, 2022 at 4:53 AM Gyan Mishra wrote: > > Robert > > > > Responses in-line > > > > > > > > On Thu, Jan 13, 2022 at 5:55 AM Robert Raszuk wrote: > > Gyan, > > > > I see what the draft is trying to do now. /* I did not even consider this > for the reason described below. */ > > > > But what you wrote requires little correction: > > > > "So now the server you are on gets overloaded and a site cost gets > advertised in the IGP at which point the connection receives a TCP reset" > > > > if you *s/connection/all connections/* then you quickly realize that what > is proposed here is a disaster. > > > >Gyan> Remember this is Anycast proximity based routing along with ECMP > / UCMP flow based load balancing and most vendors modern routers support > some sort of x-tuple ECMP/UCMP hash so the flows would be evenly > distributed, so if you have 10s of 100s of paths, the flows would be evenly > distributed across all the paths. Since it’s Anycast proximity each path > leads to a different Application LB VIP and backend server. So all the TCP > connections would be uniformly distributed across all the paths. > > > > Only the connections hashed to the path with overloaded server would get > reset and it would be no different then if the server went down as the > connections would get reset anyway in that case. > > > > In this case instead of being pinned to a bad connection you are now > reset to a good connection resulting in better QOE for the end user and a > Happy customer. > > > > To me thats a positive not a negative. > > > > A good analogy would be let’s say you are on WIFI and on the same channel > that your neighbors are on and have horrible bandwidth. Do you stay on > that bad channel and limp along all day or to you flip to an unused channel. > > > > Another example is if you have a server that has run out of resources. Do > you fail production traffic off the server taking it out of rotation or let > it stay as is and pray things get better. This draft is a good example of > how IGP can save the day with site metric. > > > > Breaking all existing flows going to one LB to suddenly timeout and all go > to the other LB(s) is never a technique any one would seriously deploy in a > production network. > > > > Gyan> Application load balancing can be done with DNS based GEO load > balancing based on client and server IP database where you have more > discrete control however the failover is much slower. > > > > Leave alone that doing that has potential to immediately overload the > other LB(s)/server(s) too. > > > > Gyan> The idea with Anycast load balancing is that you may have 10 or even > 100s of paths, so if one server fails the load can be evenly distributed > based on statistical multiplexing algorithm calculated by the server teams > engineering the sizing of the server clusters to ensure what you described > won’t happen. > > > > For me the conclusion is that IGP transport level is not the proper layer > to address the requirement. > > > > Cheers, > > Robert. > > > > > > On Thu, Jan 13, 2022 at 7:05 AM Gyan Mishra wrote: > > > > Hi Les > > > > Agreed. > > > &
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
d based on statistical multiplexing algorithm calculated by the >> server teams engineering the sizing of the server clusters to ensure what >> you described won’t happen. >> >>> >>> For me the conclusion is that IGP transport level is not the proper >>> layer to address the requirement. >>> >>> Cheers, >>> Robert. >>> >>> >>> On Thu, Jan 13, 2022 at 7:05 AM Gyan Mishra >>> wrote: >>> >>>> >>>> Hi Les >>>> >>>> Agreed. >>>> >>>> My thoughts are that the context of the draft is based on an Anycast >>>> VIP address of a server which is proximity based load balancing and not >>>> necessarily ECMP/UCMP and only if the proximity is the same for multiple >>>> paths to the Anycast VIP would there be a ECMP/UCMP possibility. >>>> >>>> Let’s say if it’s proximity based and one path is preferred, the flow >>>> will take that path. So now the server you are on gets overloaded and a >>>> site cost gets advertised in the IGP at which point the connection receives >>>> a TCP reset and flow re-establishes on the alternate path based on the site >>>> cost and remains there until the server goes down or gets overloaded or a >>>> better path comes along. >>>> >>>> For ECMP case, ECMP has flow affinity so the flow will stay on the same >>>> path long lived until the connection terminates. >>>> >>>> So now in ECMP case the flow hashed to a path and maintains its >>>> affinity to that path. Now all of sudden the server gets overloaded and we >>>> get a better site cost advertised. So now the session terminates on >>>> current path and establishes again on the Anycast VIP new path based on the >>>> site cost advertised. >>>> >>>> The failover I believe results in the user refreshing their browser >>>> which is better than hanging. >>>> >>>> As the VIP prefix is the only one that experiences reconvergence on new >>>> path based on site cost if there is any instability with the servers that >>>> will be reflected to the IGP Anycast prefix as well. >>>> >>>> Is that a good or bad thing. I think if you had to pick your poison as >>>> here the issue Linda is trying to solve is a server issue but leveraging >>>> the IGP to force re-convergence when the server is in a half baked state >>>> meaning it’s busy and connections are being dropped or very slow QOE for >>>> end user. If you did nothing and let it ride the the user would be stuck >>>> on a bad connection. >>>> >>>> So this solution dynamically fixed the issue. >>>> >>>> As far as oscillation that is not a big deal as you are in a much worse >>>> off state connected to a dying server on its last leg as far as memory and >>>> CPU. >>>> >>>> This solution I can see can apply to any client / server connection and >>>> not just 5G and can be used by enterprises as well as SP for their >>>> customers to have an drastically improved QOE. >>>> >>>> I saw some feedback on the TLV and I think once that is all worked out >>>> I am in favor of advancing this draft. >>>> >>>> Kind Regards >>>> >>>> Gyan >>>> >>>> >>>> On Wed, Jan 12, 2022 at 10:16 PM Les Ginsberg (ginsberg) < >>>> ginsb...@cisco.com> wrote: >>>> >>>>> Gyan – >>>>> >>>>> >>>>> >>>>> The difference between ECMP and UCMP is not significant in this >>>>> discussion. >>>>> >>>>> I don’t want to speak for Robert, but for me his point was that IGPs >>>>> can do “multipath” well – but this does not translate into managing flows. >>>>> >>>>> Please see my other responses on this thread. >>>>> >>>>> >>>>> >>>>> Thanx. >>>>> >>>>> >>>>> >>>>> Les >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From:* Gyan Mishra >>>>> *Sent:* Wednesday, January 12, 2022 5:26 PM >>>>> *To:* Robert Raszuk >>>>> *Cc:* Les Ginsberg (ginsberg) ; Linda Dunbar < >>>>> linda.dun...@futurewei.com>; lsr@
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
This draft is now proposing one aggregate cost of the application server. The detailed factors can also be included if necessary. But the principle for advertising them should be controllable, as required by other dynamic metrics in IGP. Aijun Wang China Telecom > On Jan 15, 2022, at 08:37, John E Drake > wrote: > > > This is similar to the issue with the Down/Up proposal. A single metric > tells an ingress node nothing about the performance of or load on the > individual applications at a given site. > > Yours Irrespectively, > > John > > > Juniper Business Use Only > From: Aijun Wang > Sent: Friday, January 14, 2022 6:58 PM > To: John E Drake > Cc: Robert Raszuk ; Gyan Mishra ; > Les Ginsberg (ginsberg) ; Linda Dunbar > ; lsr@ietf.org > Subject: Re: [Lsr] Seeking feedback to the revised > draft-dunbar-lsr-5g-edge-compute > > [External Email. Be cautious of content] > > Hi, John: > Here I would also like to hear your own opinions. If not, please see my > responses for both you and Robert: > > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con-01 has > introduced the “delay metric” into the IGP. Such metric may be variant in > every link within the IGP. > The proposal in draft-dunbar-lsr-5g-edge-compute is only for the > stub-link’s/prefixes characteristics, it is the aggregate cost to the server > that measured from the router. > > All the factors that mentioned by Robert maybe the parameters that influences > the performance of the server, which will be reflected in the aggregate cost. > > Then, the conclusion is that IGP has now the capabilities to deal with the > dynamics value(the change frequencies can certainly be controlled, thinking > how we control the flapping interface)within the network , the aggregate cost > or other quasi-static factor to the server at the edge of the network can > also be considered together. > Such approaches can certainly let the IGP give more optimal behavior to > forward the traffic to the appropriate destination, or follow an optimal path. > > Aijun Wang > China Telecom > > > On Jan 14, 2022, at 23:49, John E Drake > wrote: > > > Robert is correct on all points. > > Yours Irrespectively, > > John > > > Juniper Business Use Only > From: Lsr On Behalf Of Robert Raszuk > Sent: Friday, January 14, 2022 4:20 AM > To: Gyan Mishra > Cc: Les Ginsberg (ginsberg) ; Linda Dunbar > ; lsr@ietf.org > Subject: Re: [Lsr] Seeking feedback to the revised > draft-dunbar-lsr-5g-edge-compute > > [External Email. Be cautious of content] > > Gyan, > > This is not a network discussion. There are well proven techniques to direct > user sessions or user requests to a pool of servers deployed and operational. > All provide robust services. Network plays very little to no role in that. > > There are also lot's of factors involved in making that decision (CPU load, > RAM, Storage, IO, CPU Temp etc ...) and IMO it would be very bad to now make > IGP to carry it and make routing decisions (even if separate topology) based > on that information. > > I do not see this like a move into the right direction. That is my input. > > Kind regards, > Robert. > > > > > > > > > On Fri, Jan 14, 2022 at 4:53 AM Gyan Mishra wrote: > Robert > > Responses in-line > > > > On Thu, Jan 13, 2022 at 5:55 AM Robert Raszuk wrote: > Gyan, > > I see what the draft is trying to do now. /* I did not even consider this for > the reason described below. */ > > But what you wrote requires little correction: > > "So now the server you are on gets overloaded and a site cost gets advertised > in the IGP at which point the connection receives a TCP reset" > > if you s/connection/all connections/ then you quickly realize that what is > proposed here is a disaster. > >Gyan> Remember this is Anycast proximity based routing along with ECMP / > UCMP flow based load balancing and most vendors modern routers support some > sort of x-tuple ECMP/UCMP hash so the flows would be evenly distributed, so > if you have 10s of 100s of paths, the flows would be evenly distributed > across all the paths. Since it’s Anycast proximity each path leads to a > different Application LB VIP and backend server. So all the TCP connections > would be uniformly distributed across all the paths. > > Only the connections hashed to the path with overloaded server would get > reset and it would be no different then if the server went down as the > connections would get reset anyway in that case. >
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
This is similar to the issue with the Down/Up proposal. A single metric tells an ingress node nothing about the performance of or load on the individual applications at a given site. Yours Irrespectively, John Juniper Business Use Only From: Aijun Wang Sent: Friday, January 14, 2022 6:58 PM To: John E Drake Cc: Robert Raszuk ; Gyan Mishra ; Les Ginsberg (ginsberg) ; Linda Dunbar ; lsr@ietf.org Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute [External Email. Be cautious of content] Hi, John: Here I would also like to hear your own opinions. If not, please see my responses for both you and Robert: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con-01<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con-01__;!!NEt6yMaO-gk!Ruow7KbUPIX1YVq2nIggRiIumNPiEf58LStjoh_L_UpLze1a2LwUW21ecs19GHc$> has introduced the “delay metric” into the IGP. Such metric may be variant in every link within the IGP. The proposal in draft-dunbar-lsr-5g-edge-compute is only for the stub-link’s/prefixes characteristics, it is the aggregate cost to the server that measured from the router. All the factors that mentioned by Robert maybe the parameters that influences the performance of the server, which will be reflected in the aggregate cost. Then, the conclusion is that IGP has now the capabilities to deal with the dynamics value(the change frequencies can certainly be controlled, thinking how we control the flapping interface)within the network , the aggregate cost or other quasi-static factor to the server at the edge of the network can also be considered together. Such approaches can certainly let the IGP give more optimal behavior to forward the traffic to the appropriate destination, or follow an optimal path. Aijun Wang China Telecom On Jan 14, 2022, at 23:49, John E Drake mailto:jdrake=40juniper@dmarc.ietf.org>> wrote: Robert is correct on all points. Yours Irrespectively, John Juniper Business Use Only From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Robert Raszuk Sent: Friday, January 14, 2022 4:20 AM To: Gyan Mishra mailto:hayabusa...@gmail.com>> Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; Linda Dunbar mailto:linda.dun...@futurewei.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute [External Email. Be cautious of content] Gyan, This is not a network discussion. There are well proven techniques to direct user sessions or user requests to a pool of servers deployed and operational. All provide robust services. Network plays very little to no role in that. There are also lot's of factors involved in making that decision (CPU load, RAM, Storage, IO, CPU Temp etc ...) and IMO it would be very bad to now make IGP to carry it and make routing decisions (even if separate topology) based on that information. I do not see this like a move into the right direction. That is my input. Kind regards, Robert. On Fri, Jan 14, 2022 at 4:53 AM Gyan Mishra mailto:hayabusa...@gmail.com>> wrote: Robert Responses in-line On Thu, Jan 13, 2022 at 5:55 AM Robert Raszuk mailto:rob...@raszuk.net>> wrote: Gyan, I see what the draft is trying to do now. /* I did not even consider this for the reason described below. */ But what you wrote requires little correction: "So now the server you are on gets overloaded and a site cost gets advertised in the IGP at which point the connection receives a TCP reset" if you s/connection/all connections/ then you quickly realize that what is proposed here is a disaster. Gyan> Remember this is Anycast proximity based routing along with ECMP / UCMP flow based load balancing and most vendors modern routers support some sort of x-tuple ECMP/UCMP hash so the flows would be evenly distributed, so if you have 10s of 100s of paths, the flows would be evenly distributed across all the paths. Since it’s Anycast proximity each path leads to a different Application LB VIP and backend server. So all the TCP connections would be uniformly distributed across all the paths. Only the connections hashed to the path with overloaded server would get reset and it would be no different then if the server went down as the connections would get reset anyway in that case. In this case instead of being pinned to a bad connection you are now reset to a good connection resulting in better QOE for the end user and a Happy customer. To me thats a positive not a negative. A good analogy would be let’s say you are on WIFI and on the same channel that your neighbors are on and have horrible bandwidth. Do you stay on that bad channel and limp along all day or to you flip to an unused channel. Another example is if you have a server that has run out of resources. Do you fail production traffic off
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Hi, John: Here I would also like to hear your own opinions. If not, please see my responses for both you and Robert: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con-01 has introduced the “delay metric” into the IGP. Such metric may be variant in every link within the IGP. The proposal in draft-dunbar-lsr-5g-edge-compute is only for the stub-link’s/prefixes characteristics, it is the aggregate cost to the server that measured from the router. All the factors that mentioned by Robert maybe the parameters that influences the performance of the server, which will be reflected in the aggregate cost. Then, the conclusion is that IGP has now the capabilities to deal with the dynamics value(the change frequencies can certainly be controlled, thinking how we control the flapping interface)within the network , the aggregate cost or other quasi-static factor to the server at the edge of the network can also be considered together. Such approaches can certainly let the IGP give more optimal behavior to forward the traffic to the appropriate destination, or follow an optimal path. Aijun Wang China Telecom > On Jan 14, 2022, at 23:49, John E Drake > wrote: > > > Robert is correct on all points. > > Yours Irrespectively, > > John > > > Juniper Business Use Only > From: Lsr On Behalf Of Robert Raszuk > Sent: Friday, January 14, 2022 4:20 AM > To: Gyan Mishra > Cc: Les Ginsberg (ginsberg) ; Linda Dunbar > ; lsr@ietf.org > Subject: Re: [Lsr] Seeking feedback to the revised > draft-dunbar-lsr-5g-edge-compute > > [External Email. Be cautious of content] > > Gyan, > > This is not a network discussion. There are well proven techniques to direct > user sessions or user requests to a pool of servers deployed and operational. > All provide robust services. Network plays very little to no role in that. > > There are also lot's of factors involved in making that decision (CPU load, > RAM, Storage, IO, CPU Temp etc ...) and IMO it would be very bad to now make > IGP to carry it and make routing decisions (even if separate topology) based > on that information. > > I do not see this like a move into the right direction. That is my input. > > Kind regards, > Robert. > > > > > > > > > On Fri, Jan 14, 2022 at 4:53 AM Gyan Mishra wrote: > Robert > > Responses in-line > > > > On Thu, Jan 13, 2022 at 5:55 AM Robert Raszuk wrote: > Gyan, > > I see what the draft is trying to do now. /* I did not even consider this for > the reason described below. */ > > But what you wrote requires little correction: > > "So now the server you are on gets overloaded and a site cost gets advertised > in the IGP at which point the connection receives a TCP reset" > > if you s/connection/all connections/ then you quickly realize that what is > proposed here is a disaster. > >Gyan> Remember this is Anycast proximity based routing along with ECMP / > UCMP flow based load balancing and most vendors modern routers support some > sort of x-tuple ECMP/UCMP hash so the flows would be evenly distributed, so > if you have 10s of 100s of paths, the flows would be evenly distributed > across all the paths. Since it’s Anycast proximity each path leads to a > different Application LB VIP and backend server. So all the TCP connections > would be uniformly distributed across all the paths. > > Only the connections hashed to the path with overloaded server would get > reset and it would be no different then if the server went down as the > connections would get reset anyway in that case. > > In this case instead of being pinned to a bad connection you are now reset > to a good connection resulting in better QOE for the end user and a Happy > customer. > > To me thats a positive not a negative. > > A good analogy would be let’s say you are on WIFI and on the same channel > that your neighbors are on and have horrible bandwidth. Do you stay on that > bad channel and limp along all day or to you flip to an unused channel. > > Another example is if you have a server that has run out of resources. Do > you fail production traffic off the server taking it out of rotation or let > it stay as is and pray things get better. This draft is a good example of > how IGP can save the day with site metric. > > Breaking all existing flows going to one LB to suddenly timeout and all go to > the other LB(s) is never a technique any one would seriously deploy in a > production network. > > Gyan> Application load balancing can be done with DNS based GEO load > balancing based on client and server IP database where
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Robert is correct on all points. Yours Irrespectively, John Juniper Business Use Only From: Lsr On Behalf Of Robert Raszuk Sent: Friday, January 14, 2022 4:20 AM To: Gyan Mishra Cc: Les Ginsberg (ginsberg) ; Linda Dunbar ; lsr@ietf.org Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute [External Email. Be cautious of content] Gyan, This is not a network discussion. There are well proven techniques to direct user sessions or user requests to a pool of servers deployed and operational. All provide robust services. Network plays very little to no role in that. There are also lot's of factors involved in making that decision (CPU load, RAM, Storage, IO, CPU Temp etc ...) and IMO it would be very bad to now make IGP to carry it and make routing decisions (even if separate topology) based on that information. I do not see this like a move into the right direction. That is my input. Kind regards, Robert. On Fri, Jan 14, 2022 at 4:53 AM Gyan Mishra mailto:hayabusa...@gmail.com>> wrote: Robert Responses in-line On Thu, Jan 13, 2022 at 5:55 AM Robert Raszuk mailto:rob...@raszuk.net>> wrote: Gyan, I see what the draft is trying to do now. /* I did not even consider this for the reason described below. */ But what you wrote requires little correction: "So now the server you are on gets overloaded and a site cost gets advertised in the IGP at which point the connection receives a TCP reset" if you s/connection/all connections/ then you quickly realize that what is proposed here is a disaster. Gyan> Remember this is Anycast proximity based routing along with ECMP / UCMP flow based load balancing and most vendors modern routers support some sort of x-tuple ECMP/UCMP hash so the flows would be evenly distributed, so if you have 10s of 100s of paths, the flows would be evenly distributed across all the paths. Since it's Anycast proximity each path leads to a different Application LB VIP and backend server. So all the TCP connections would be uniformly distributed across all the paths. Only the connections hashed to the path with overloaded server would get reset and it would be no different then if the server went down as the connections would get reset anyway in that case. In this case instead of being pinned to a bad connection you are now reset to a good connection resulting in better QOE for the end user and a Happy customer. To me thats a positive not a negative. A good analogy would be let's say you are on WIFI and on the same channel that your neighbors are on and have horrible bandwidth. Do you stay on that bad channel and limp along all day or to you flip to an unused channel. Another example is if you have a server that has run out of resources. Do you fail production traffic off the server taking it out of rotation or let it stay as is and pray things get better. This draft is a good example of how IGP can save the day with site metric. Breaking all existing flows going to one LB to suddenly timeout and all go to the other LB(s) is never a technique any one would seriously deploy in a production network. Gyan> Application load balancing can be done with DNS based GEO load balancing based on client and server IP database where you have more discrete control however the failover is much slower. Leave alone that doing that has potential to immediately overload the other LB(s)/server(s) too. Gyan> The idea with Anycast load balancing is that you may have 10 or even 100s of paths, so if one server fails the load can be evenly distributed based on statistical multiplexing algorithm calculated by the server teams engineering the sizing of the server clusters to ensure what you described won't happen. For me the conclusion is that IGP transport level is not the proper layer to address the requirement. Cheers, Robert. On Thu, Jan 13, 2022 at 7:05 AM Gyan Mishra mailto:hayabusa...@gmail.com>> wrote: Hi Les Agreed. My thoughts are that the context of the draft is based on an Anycast VIP address of a server which is proximity based load balancing and not necessarily ECMP/UCMP and only if the proximity is the same for multiple paths to the Anycast VIP would there be a ECMP/UCMP possibility. Let's say if it's proximity based and one path is preferred, the flow will take that path. So now the server you are on gets overloaded and a site cost gets advertised in the IGP at which point the connection receives a TCP reset and flow re-establishes on the alternate path based on the site cost and remains there until the server goes down or gets overloaded or a better path comes along. For ECMP case, ECMP has flow affinity so the flow will stay on the same path long lived until the connection terminates. So now in ECMP case the flow hashed to a path and maintains its affinity to that path. Now all of sudden the server gets overloaded and we get a
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
the flow will stay on the same >>> path long lived until the connection terminates. >>> >>> So now in ECMP case the flow hashed to a path and maintains its affinity >>> to that path. Now all of sudden the server gets overloaded and we get a >>> better site cost advertised. So now the session terminates on current path >>> and establishes again on the Anycast VIP new path based on the site cost >>> advertised. >>> >>> The failover I believe results in the user refreshing their browser >>> which is better than hanging. >>> >>> As the VIP prefix is the only one that experiences reconvergence on new >>> path based on site cost if there is any instability with the servers that >>> will be reflected to the IGP Anycast prefix as well. >>> >>> Is that a good or bad thing. I think if you had to pick your poison as >>> here the issue Linda is trying to solve is a server issue but leveraging >>> the IGP to force re-convergence when the server is in a half baked state >>> meaning it’s busy and connections are being dropped or very slow QOE for >>> end user. If you did nothing and let it ride the the user would be stuck >>> on a bad connection. >>> >>> So this solution dynamically fixed the issue. >>> >>> As far as oscillation that is not a big deal as you are in a much worse >>> off state connected to a dying server on its last leg as far as memory and >>> CPU. >>> >>> This solution I can see can apply to any client / server connection and >>> not just 5G and can be used by enterprises as well as SP for their >>> customers to have an drastically improved QOE. >>> >>> I saw some feedback on the TLV and I think once that is all worked out I >>> am in favor of advancing this draft. >>> >>> Kind Regards >>> >>> Gyan >>> >>> >>> On Wed, Jan 12, 2022 at 10:16 PM Les Ginsberg (ginsberg) < >>> ginsb...@cisco.com> wrote: >>> >>>> Gyan – >>>> >>>> >>>> >>>> The difference between ECMP and UCMP is not significant in this >>>> discussion. >>>> >>>> I don’t want to speak for Robert, but for me his point was that IGPs >>>> can do “multipath” well – but this does not translate into managing flows. >>>> >>>> Please see my other responses on this thread. >>>> >>>> >>>> >>>> Thanx. >>>> >>>> >>>> >>>> Les >>>> >>>> >>>> >>>> >>>> >>>> *From:* Gyan Mishra >>>> *Sent:* Wednesday, January 12, 2022 5:26 PM >>>> *To:* Robert Raszuk >>>> *Cc:* Les Ginsberg (ginsberg) ; Linda Dunbar < >>>> linda.dun...@futurewei.com>; lsr@ietf.org >>>> *Subject:* Re: [Lsr] Seeking feedback to the revised >>>> draft-dunbar-lsr-5g-edge-compute >>>> >>>> >>>> >>>> >>>> >>>> Robert >>>> >>>> >>>> >>>> Here are a few examples of UCMP drafts below used in core and data >>>> center use cases. >>>> >>>> >>>> >>>> https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-unequal-lb-15 >>>> >>>> >>>> >>>> https://datatracker.ietf.org/doc/html/draft-mohanty-bess-weighted-hrw-02 >>>> >>>> >>>> >>>> https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth >>>> >>>> >>>> >>>> https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> There are many use cases in routing for unequal cost load balancing >>>> capabilities. >>>> >>>> >>>> >>>> Kind Regards >>>> >>>> >>>> >>>> Gyan >>>> >>>> >>>> >>>> On Wed, Jan 12, 2022 at 2:23 PM Robert Raszuk >>>> wrote: >>>> >>>> Linda, >>>> >>>> >>>> >>>> > IGP has been used for the Multi-path computation for a long time >>>> >>>> >>>> >>>> IGP can and does ECMP well. Moreover, injecting metric of anycast &
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
usy and connections are being dropped or very slow QOE for >> end user. If you did nothing and let it ride the the user would be stuck >> on a bad connection. >> >> So this solution dynamically fixed the issue. >> >> As far as oscillation that is not a big deal as you are in a much worse >> off state connected to a dying server on its last leg as far as memory and >> CPU. >> >> This solution I can see can apply to any client / server connection and >> not just 5G and can be used by enterprises as well as SP for their >> customers to have an drastically improved QOE. >> >> I saw some feedback on the TLV and I think once that is all worked out I >> am in favor of advancing this draft. >> >> Kind Regards >> >> Gyan >> >> >> On Wed, Jan 12, 2022 at 10:16 PM Les Ginsberg (ginsberg) < >> ginsb...@cisco.com> wrote: >> >>> Gyan – >>> >>> >>> >>> The difference between ECMP and UCMP is not significant in this >>> discussion. >>> >>> I don’t want to speak for Robert, but for me his point was that IGPs can >>> do “multipath” well – but this does not translate into managing flows. >>> >>> Please see my other responses on this thread. >>> >>> >>> >>> Thanx. >>> >>> >>> >>> Les >>> >>> >>> >>> >>> >>> *From:* Gyan Mishra >>> *Sent:* Wednesday, January 12, 2022 5:26 PM >>> *To:* Robert Raszuk >>> *Cc:* Les Ginsberg (ginsberg) ; Linda Dunbar < >>> linda.dun...@futurewei.com>; lsr@ietf.org >>> *Subject:* Re: [Lsr] Seeking feedback to the revised >>> draft-dunbar-lsr-5g-edge-compute >>> >>> >>> >>> >>> >>> Robert >>> >>> >>> >>> Here are a few examples of UCMP drafts below used in core and data >>> center use cases. >>> >>> >>> >>> https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-unequal-lb-15 >>> >>> >>> >>> https://datatracker.ietf.org/doc/html/draft-mohanty-bess-weighted-hrw-02 >>> >>> >>> >>> https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth >>> >>> >>> >>> https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz >>> >>> >>> >>> >>> >>> >>> >>> There are many use cases in routing for unequal cost load balancing >>> capabilities. >>> >>> >>> >>> Kind Regards >>> >>> >>> >>> Gyan >>> >>> >>> >>> On Wed, Jan 12, 2022 at 2:23 PM Robert Raszuk wrote: >>> >>> Linda, >>> >>> >>> >>> > IGP has been used for the Multi-path computation for a long time >>> >>> >>> >>> IGP can and does ECMP well. Moreover, injecting metric of anycast server >>> destination plays no role in it as all paths would inherit that external to >>> the IGP cost. >>> >>> >>> >>> Unequal cost load balancing or intelligent traffic spread has always >>> been done at the application layer *for example MPLS* >>> >>> >>> >>> Thx a lot, >>> >>> R. >>> >>> >>> >>> On Wed, Jan 12, 2022 at 8:18 PM Linda Dunbar >>> wrote: >>> >>> Robert, >>> >>> >>> >>> Please see inline in green: >>> >>> >>> >>> *From:* Robert Raszuk >>> *Sent:* Wednesday, January 12, 2022 1:00 PM >>> *To:* Linda Dunbar >>> *Cc:* Les Ginsberg (ginsberg) ; lsr@ietf.org >>> *Subject:* Re: [Lsr] Seeking feedback to the revised >>> draft-dunbar-lsr-5g-edge-compute >>> >>> >>> >>> Hi Linda, >>> >>> >>> >>> *[LES:] It is my opinion that what you propose will not achieve your >>> goals – in part because IGPs only influence forwarding on a per packet >>> basis – not a per flow/connection basis.* >>> >>> *[Linda] Most vendors do support flow based ECMP, with Shortest Path >>> computed by attributes advertised by IGP.* >>> >>> >>> >>> I am with Les here. ECMP has nothing to do with his point. >>> >>> >>> >>> [Linda] Les said that “IGP only influen
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
> My agreement on the use of the IGP assumes that the entity calculating the metric > to be provided to the IGP has the correct intelligence. I would not count on that We have seen intelligent entities claiming to optimize routing having bugs and missing corner cases which in turn when injected into routing protocols results in massive (often global if we think BGP) unreachability. Point here is that if we are to take dynamic data of any smart oracle to use for making routing decisions (this is not really TE IMO) we better have day one build in fuses and auto breakers to detect and suppress the potential damage. Thx, R. On Thu, Jan 13, 2022 at 7:12 PM Les Ginsberg (ginsberg) wrote: > Robert – > > > > I agree there is still a concern here – which has to do with how the new > metric is calculated. > > > > Imagine that I have a million users in a metro area and they are all WFH > (gee – when would that ever happen?? ) So they aren’t really mobile. > > Are we going to have all users initially directed to Server #1 – and then > after some period move all users to Server #2 just because Server #1 is > busier than Server #2? (I hope not) > > It seems to me that how the metric is calculated has cross-site > implications. > > This is out of scope for the IGP – we simply use what we are given. > > But whatever entity is calculating the metric to be used has to be able to > do so in a way that doesn’t cause spurious rerouting. > > > > Seems to me you are asking Linda this question in one of your other posts. > > > > My agreement on the use of the IGP assumes that the entity calculating the > metric to be provided to the IGP has the correct intelligence. > > > >Les > > > > > > *From:* Robert Raszuk > *Sent:* Thursday, January 13, 2022 8:52 AM > *To:* Les Ginsberg (ginsberg) > *Cc:* Linda Dunbar ; Gyan Mishra < > hayabusa...@gmail.com>; lsr@ietf.org > *Subject:* Re: [Lsr] Seeking feedback to the revised > draft-dunbar-lsr-5g-edge-compute > > > > > > > and I agree that using the IGP/Flex Algo as you are proposing is a > viable solution. > > > > Except that IGP usually does not run between application server and load > balancer ... > > > > > > On Thu, Jan 13, 2022 at 5:37 PM Les Ginsberg (ginsberg) < > ginsb...@cisco.com> wrote: > > Linda – > > > > Are you saying that the scenario you are trying to address is to have a > given “transaction” go to the currently closest/most lightly loaded > Application Server? > > And there is no intent to support for long lived connections? > > > > If so, then this isn’t really a load balancing issue and I agree that > using the IGP/Flex Algo as you are proposing is a viable solution. > > The concern then becomes the rate of updates to the new Prefix Metric. If > this changes too rapidly this will heavily consume network resources by > triggering flooding, SPF, forwarding plane updates at a high rate. > > Can you put some language in the draft that indicates the expected rate of > updates to the metric and some guidelines on limiting the frequency? > > > > Thanx. > > > >Les > > > > > > *From:* Linda Dunbar > *Sent:* Thursday, January 13, 2022 7:58 AM > *To:* Robert Raszuk > *Cc:* Gyan Mishra ; Les Ginsberg (ginsberg) < > ginsb...@cisco.com>; lsr@ietf.org > *Subject:* RE: [Lsr] Seeking feedback to the revised > draft-dunbar-lsr-5g-edge-compute > > > > Robert, > > > > For your scenario of TCP flows lasting more than 8~18 hours, multiple > server instances SHOULDN’T be assigned with the SAME IP address (ANYCAST > address). Each of those instances should have one distinct IP address. > > > > The draft is for different scenario where application are instantiated at > multiple locations behind multiple App Layer Load Balancers. They have > relative short flows that can go to any App Layer Load Balancers. Multiple > Load Balancers for those applications are assigned with the same IP > address. In Kubernetes, multiple load balancers for one type of > microservices are assigned with one single Virtual IP address, so that the > network can forward as one single destination. > > > > Linda > > *From:* Robert Raszuk > *Sent:* Thursday, January 13, 2022 9:37 AM > *To:* Linda Dunbar > *Cc:* Gyan Mishra ; Les Ginsberg (ginsberg) < > ginsb...@cisco.com>; lsr@ietf.org > *Subject:* Re: [Lsr] Seeking feedback to the revised > draft-dunbar-lsr-5g-edge-compute > > > > > > > Flows among micro-services are very short. > > > > While that can be true - there is nowhere in the document a restriction
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Robert – I agree there is still a concern here – which has to do with how the new metric is calculated. Imagine that I have a million users in a metro area and they are all WFH (gee – when would that ever happen?? ) So they aren’t really mobile. Are we going to have all users initially directed to Server #1 – and then after some period move all users to Server #2 just because Server #1 is busier than Server #2? (I hope not) It seems to me that how the metric is calculated has cross-site implications. This is out of scope for the IGP – we simply use what we are given. But whatever entity is calculating the metric to be used has to be able to do so in a way that doesn’t cause spurious rerouting. Seems to me you are asking Linda this question in one of your other posts. My agreement on the use of the IGP assumes that the entity calculating the metric to be provided to the IGP has the correct intelligence. Les From: Robert Raszuk Sent: Thursday, January 13, 2022 8:52 AM To: Les Ginsberg (ginsberg) Cc: Linda Dunbar ; Gyan Mishra ; lsr@ietf.org Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute > and I agree that using the IGP/Flex Algo as you are proposing is a viable > solution. Except that IGP usually does not run between application server and load balancer ... On Thu, Jan 13, 2022 at 5:37 PM Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>> wrote: Linda – Are you saying that the scenario you are trying to address is to have a given “transaction” go to the currently closest/most lightly loaded Application Server? And there is no intent to support for long lived connections? If so, then this isn’t really a load balancing issue and I agree that using the IGP/Flex Algo as you are proposing is a viable solution. The concern then becomes the rate of updates to the new Prefix Metric. If this changes too rapidly this will heavily consume network resources by triggering flooding, SPF, forwarding plane updates at a high rate. Can you put some language in the draft that indicates the expected rate of updates to the metric and some guidelines on limiting the frequency? Thanx. Les From: Linda Dunbar mailto:linda.dun...@futurewei.com>> Sent: Thursday, January 13, 2022 7:58 AM To: Robert Raszuk mailto:rob...@raszuk.net>> Cc: Gyan Mishra mailto:hayabusa...@gmail.com>>; Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: RE: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Robert, For your scenario of TCP flows lasting more than 8~18 hours, multiple server instances SHOULDN’T be assigned with the SAME IP address (ANYCAST address). Each of those instances should have one distinct IP address. The draft is for different scenario where application are instantiated at multiple locations behind multiple App Layer Load Balancers. They have relative short flows that can go to any App Layer Load Balancers. Multiple Load Balancers for those applications are assigned with the same IP address. In Kubernetes, multiple load balancers for one type of microservices are assigned with one single Virtual IP address, so that the network can forward as one single destination. Linda From: Robert Raszuk mailto:rob...@raszuk.net>> Sent: Thursday, January 13, 2022 9:37 AM To: Linda Dunbar mailto:linda.dun...@futurewei.com>> Cc: Gyan Mishra mailto:hayabusa...@gmail.com>>; Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute > Flows among micro-services are very short. While that can be true - there is nowhere in the document a restriction or even a warning that this solution is aiming for short lived flows only and that users should be well aware about drastic nature of proposed mechanism to their established flows. In one of the companies I worked for average TCP flow duration was anywhere from 8-18 hours and it was a very drastic event for the user to loose it in the middle of the day. Various means where taken and applied to protect such sessions from any form of disconnects. I think we are shooting here with the wrong weapon to the target. Thx, R. On Thu, Jan 13, 2022 at 4:23 PM Linda Dunbar mailto:linda.dun...@futurewei.com>> wrote: Robert, Your link to Traefik adds more reasons why “Site index and preference” should be distributed by IGP: * Site index and preferences for a cluster of micro-service instances are rarely dynamically changed. Most of those values are configured. Therefore, the oscillation is minimal. * Flows among micro-services are very short. Put less requirements to flow affinity. * Linda From: Robert Raszuk mailto:rob...@raszuk.net>> Sent: Thursday, January 13, 2022 5:00 AM To: Gyan Mishra mailto:hayabusa...@gmail.com>
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
I am asking not for static assigned values by cfg. I am asking for dynamic values being as part of site cost your draft is describing here: The "Site-Cost", which is derived from "site-capacity + load measurement + Preference + xxx", can be raw measurements collected by the egress routers based on the instructions from a controller or can be informed by the App Controller periodically. Draft says "collected" - I am asking how is it collected ? Thx On Thu, Jan 13, 2022 at 6:29 PM Linda Dunbar wrote: > Robert, > > > > Egress routers can be assigned with a site preference index for a specific > set of prefixes attached. > > > > Linda > > > > *From:* Robert Raszuk > *Sent:* Thursday, January 13, 2022 11:27 AM > *To:* Linda Dunbar > *Cc:* Les Ginsberg (ginsberg) ; Gyan Mishra < > hayabusa...@gmail.com>; lsr@ietf.org > *Subject:* Re: [Lsr] Seeking feedback to the revised > draft-dunbar-lsr-5g-edge-compute > > > > Linda, > > > > Let me ask again ... How does ISIS process on the egress router learns the > load of the "attached" load balancer ? > > > > As far as your comment on using or not using anycast addresses I disagree, > but we will not be spamming LSR WG list to discuss this further. > > > > Thx a lot, > > R. > > > > On Thu, Jan 13, 2022 at 6:18 PM Linda Dunbar > wrote: > > Robert, > > > > The draft is about distributing the Site Index and preferences of the > Egress routers to which the application load balancers (or instances) are > attached. > > > > Thanks, Linda > > > > *From:* Robert Raszuk > *Sent:* Thursday, January 13, 2022 10:52 AM > *To:* Les Ginsberg (ginsberg) > *Cc:* Linda Dunbar ; Gyan Mishra < > hayabusa...@gmail.com>; lsr@ietf.org > *Subject:* Re: [Lsr] Seeking feedback to the revised > draft-dunbar-lsr-5g-edge-compute > > > > > > > and I agree that using the IGP/Flex Algo as you are proposing is a > viable solution. > > > > Except that IGP usually does not run between application server and load > balancer ... > > > > > > On Thu, Jan 13, 2022 at 5:37 PM Les Ginsberg (ginsberg) < > ginsb...@cisco.com> wrote: > > Linda – > > > > Are you saying that the scenario you are trying to address is to have a > given “transaction” go to the currently closest/most lightly loaded > Application Server? > > And there is no intent to support for long lived connections? > > > > If so, then this isn’t really a load balancing issue and I agree that > using the IGP/Flex Algo as you are proposing is a viable solution. > > The concern then becomes the rate of updates to the new Prefix Metric. If > this changes too rapidly this will heavily consume network resources by > triggering flooding, SPF, forwarding plane updates at a high rate. > > Can you put some language in the draft that indicates the expected rate of > updates to the metric and some guidelines on limiting the frequency? > > > > Thanx. > > > >Les > > > > > > *From:* Linda Dunbar > *Sent:* Thursday, January 13, 2022 7:58 AM > *To:* Robert Raszuk > *Cc:* Gyan Mishra ; Les Ginsberg (ginsberg) < > ginsb...@cisco.com>; lsr@ietf.org > *Subject:* RE: [Lsr] Seeking feedback to the revised > draft-dunbar-lsr-5g-edge-compute > > > > Robert, > > > > For your scenario of TCP flows lasting more than 8~18 hours, multiple > server instances SHOULDN’T be assigned with the SAME IP address (ANYCAST > address). Each of those instances should have one distinct IP address. > > > > The draft is for different scenario where application are instantiated at > multiple locations behind multiple App Layer Load Balancers. They have > relative short flows that can go to any App Layer Load Balancers. Multiple > Load Balancers for those applications are assigned with the same IP > address. In Kubernetes, multiple load balancers for one type of > microservices are assigned with one single Virtual IP address, so that the > network can forward as one single destination. > > > > Linda > > *From:* Robert Raszuk > *Sent:* Thursday, January 13, 2022 9:37 AM > *To:* Linda Dunbar > *Cc:* Gyan Mishra ; Les Ginsberg (ginsberg) < > ginsb...@cisco.com>; lsr@ietf.org > *Subject:* Re: [Lsr] Seeking feedback to the revised > draft-dunbar-lsr-5g-edge-compute > > > > > > > Flows among micro-services are very short. > > > > While that can be true - there is nowhere in the document a restriction or > even a warning that this solution is aiming for short lived flows only and >
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Robert, Egress routers can be assigned with a site preference index for a specific set of prefixes attached. Linda From: Robert Raszuk Sent: Thursday, January 13, 2022 11:27 AM To: Linda Dunbar Cc: Les Ginsberg (ginsberg) ; Gyan Mishra ; lsr@ietf.org Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Linda, Let me ask again ... How does ISIS process on the egress router learns the load of the "attached" load balancer ? As far as your comment on using or not using anycast addresses I disagree, but we will not be spamming LSR WG list to discuss this further. Thx a lot, R. On Thu, Jan 13, 2022 at 6:18 PM Linda Dunbar mailto:linda.dun...@futurewei.com>> wrote: Robert, The draft is about distributing the Site Index and preferences of the Egress routers to which the application load balancers (or instances) are attached. Thanks, Linda From: Robert Raszuk mailto:rob...@raszuk.net>> Sent: Thursday, January 13, 2022 10:52 AM To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>> Cc: Linda Dunbar mailto:linda.dun...@futurewei.com>>; Gyan Mishra mailto:hayabusa...@gmail.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute > and I agree that using the IGP/Flex Algo as you are proposing is a viable > solution. Except that IGP usually does not run between application server and load balancer ... On Thu, Jan 13, 2022 at 5:37 PM Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>> wrote: Linda - Are you saying that the scenario you are trying to address is to have a given "transaction" go to the currently closest/most lightly loaded Application Server? And there is no intent to support for long lived connections? If so, then this isn't really a load balancing issue and I agree that using the IGP/Flex Algo as you are proposing is a viable solution. The concern then becomes the rate of updates to the new Prefix Metric. If this changes too rapidly this will heavily consume network resources by triggering flooding, SPF, forwarding plane updates at a high rate. Can you put some language in the draft that indicates the expected rate of updates to the metric and some guidelines on limiting the frequency? Thanx. Les From: Linda Dunbar mailto:linda.dun...@futurewei.com>> Sent: Thursday, January 13, 2022 7:58 AM To: Robert Raszuk mailto:rob...@raszuk.net>> Cc: Gyan Mishra mailto:hayabusa...@gmail.com>>; Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: RE: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Robert, For your scenario of TCP flows lasting more than 8~18 hours, multiple server instances SHOULDN'T be assigned with the SAME IP address (ANYCAST address). Each of those instances should have one distinct IP address. The draft is for different scenario where application are instantiated at multiple locations behind multiple App Layer Load Balancers. They have relative short flows that can go to any App Layer Load Balancers. Multiple Load Balancers for those applications are assigned with the same IP address. In Kubernetes, multiple load balancers for one type of microservices are assigned with one single Virtual IP address, so that the network can forward as one single destination. Linda From: Robert Raszuk mailto:rob...@raszuk.net>> Sent: Thursday, January 13, 2022 9:37 AM To: Linda Dunbar mailto:linda.dun...@futurewei.com>> Cc: Gyan Mishra mailto:hayabusa...@gmail.com>>; Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute > Flows among micro-services are very short. While that can be true - there is nowhere in the document a restriction or even a warning that this solution is aiming for short lived flows only and that users should be well aware about drastic nature of proposed mechanism to their established flows. In one of the companies I worked for average TCP flow duration was anywhere from 8-18 hours and it was a very drastic event for the user to loose it in the middle of the day. Various means where taken and applied to protect such sessions from any form of disconnects. I think we are shooting here with the wrong weapon to the target. Thx, R. On Thu, Jan 13, 2022 at 4:23 PM Linda Dunbar mailto:linda.dun...@futurewei.com>> wrote: Robert, Your link to Traefik adds more reasons why "Site index and preference" should be distributed by IGP: * Site index and preferences for a cluster of micro-service instances are rarely dynamically changed. Most of those values are configured. Therefore, the oscillation is minimal. * Flows among micro-services are very short. Put less requirements to f
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Linda, Let me ask again ... How does ISIS process on the egress router learns the load of the "attached" load balancer ? As far as your comment on using or not using anycast addresses I disagree, but we will not be spamming LSR WG list to discuss this further. Thx a lot, R. On Thu, Jan 13, 2022 at 6:18 PM Linda Dunbar wrote: > Robert, > > > > The draft is about distributing the Site Index and preferences of the > Egress routers to which the application load balancers (or instances) are > attached. > > > > Thanks, Linda > > > > *From:* Robert Raszuk > *Sent:* Thursday, January 13, 2022 10:52 AM > *To:* Les Ginsberg (ginsberg) > *Cc:* Linda Dunbar ; Gyan Mishra < > hayabusa...@gmail.com>; lsr@ietf.org > *Subject:* Re: [Lsr] Seeking feedback to the revised > draft-dunbar-lsr-5g-edge-compute > > > > > > > and I agree that using the IGP/Flex Algo as you are proposing is a > viable solution. > > > > Except that IGP usually does not run between application server and load > balancer ... > > > > > > On Thu, Jan 13, 2022 at 5:37 PM Les Ginsberg (ginsberg) < > ginsb...@cisco.com> wrote: > > Linda – > > > > Are you saying that the scenario you are trying to address is to have a > given “transaction” go to the currently closest/most lightly loaded > Application Server? > > And there is no intent to support for long lived connections? > > > > If so, then this isn’t really a load balancing issue and I agree that > using the IGP/Flex Algo as you are proposing is a viable solution. > > The concern then becomes the rate of updates to the new Prefix Metric. If > this changes too rapidly this will heavily consume network resources by > triggering flooding, SPF, forwarding plane updates at a high rate. > > Can you put some language in the draft that indicates the expected rate of > updates to the metric and some guidelines on limiting the frequency? > > > > Thanx. > > > >Les > > > > > > *From:* Linda Dunbar > *Sent:* Thursday, January 13, 2022 7:58 AM > *To:* Robert Raszuk > *Cc:* Gyan Mishra ; Les Ginsberg (ginsberg) < > ginsb...@cisco.com>; lsr@ietf.org > *Subject:* RE: [Lsr] Seeking feedback to the revised > draft-dunbar-lsr-5g-edge-compute > > > > Robert, > > > > For your scenario of TCP flows lasting more than 8~18 hours, multiple > server instances SHOULDN’T be assigned with the SAME IP address (ANYCAST > address). Each of those instances should have one distinct IP address. > > > > The draft is for different scenario where application are instantiated at > multiple locations behind multiple App Layer Load Balancers. They have > relative short flows that can go to any App Layer Load Balancers. Multiple > Load Balancers for those applications are assigned with the same IP > address. In Kubernetes, multiple load balancers for one type of > microservices are assigned with one single Virtual IP address, so that the > network can forward as one single destination. > > > > Linda > > *From:* Robert Raszuk > *Sent:* Thursday, January 13, 2022 9:37 AM > *To:* Linda Dunbar > *Cc:* Gyan Mishra ; Les Ginsberg (ginsberg) < > ginsb...@cisco.com>; lsr@ietf.org > *Subject:* Re: [Lsr] Seeking feedback to the revised > draft-dunbar-lsr-5g-edge-compute > > > > > > > Flows among micro-services are very short. > > > > While that can be true - there is nowhere in the document a restriction or > even a warning that this solution is aiming for short lived flows only and > that users should be well aware about drastic nature of proposed > mechanism to their established flows. > > > > In one of the companies I worked for average TCP flow duration was > anywhere from 8-18 hours and it was a very drastic event for the user to > loose it in the middle of the day. Various means where taken and applied > to protect such sessions from any form of disconnects. > > > > I think we are shooting here with the wrong weapon to the target. > > > > Thx, > > R. > > > > On Thu, Jan 13, 2022 at 4:23 PM Linda Dunbar > wrote: > > Robert, > > > > Your link to Traefik adds more reasons why “Site index and preference” > should be distributed by IGP: > >- Site index and preferences for a cluster of micro-service instances >are rarely dynamically changed. Most of those values are configured. >Therefore, the oscillation is minimal. >- Flows among micro-services are very short. Put less requirements to >flow affinity. >- > > > > Linda > > > > > > *From:* Robe
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Robert, The draft is about distributing the Site Index and preferences of the Egress routers to which the application load balancers (or instances) are attached. Thanks, Linda From: Robert Raszuk Sent: Thursday, January 13, 2022 10:52 AM To: Les Ginsberg (ginsberg) Cc: Linda Dunbar ; Gyan Mishra ; lsr@ietf.org Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute > and I agree that using the IGP/Flex Algo as you are proposing is a viable > solution. Except that IGP usually does not run between application server and load balancer ... On Thu, Jan 13, 2022 at 5:37 PM Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>> wrote: Linda - Are you saying that the scenario you are trying to address is to have a given "transaction" go to the currently closest/most lightly loaded Application Server? And there is no intent to support for long lived connections? If so, then this isn't really a load balancing issue and I agree that using the IGP/Flex Algo as you are proposing is a viable solution. The concern then becomes the rate of updates to the new Prefix Metric. If this changes too rapidly this will heavily consume network resources by triggering flooding, SPF, forwarding plane updates at a high rate. Can you put some language in the draft that indicates the expected rate of updates to the metric and some guidelines on limiting the frequency? Thanx. Les From: Linda Dunbar mailto:linda.dun...@futurewei.com>> Sent: Thursday, January 13, 2022 7:58 AM To: Robert Raszuk mailto:rob...@raszuk.net>> Cc: Gyan Mishra mailto:hayabusa...@gmail.com>>; Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: RE: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Robert, For your scenario of TCP flows lasting more than 8~18 hours, multiple server instances SHOULDN'T be assigned with the SAME IP address (ANYCAST address). Each of those instances should have one distinct IP address. The draft is for different scenario where application are instantiated at multiple locations behind multiple App Layer Load Balancers. They have relative short flows that can go to any App Layer Load Balancers. Multiple Load Balancers for those applications are assigned with the same IP address. In Kubernetes, multiple load balancers for one type of microservices are assigned with one single Virtual IP address, so that the network can forward as one single destination. Linda From: Robert Raszuk mailto:rob...@raszuk.net>> Sent: Thursday, January 13, 2022 9:37 AM To: Linda Dunbar mailto:linda.dun...@futurewei.com>> Cc: Gyan Mishra mailto:hayabusa...@gmail.com>>; Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute > Flows among micro-services are very short. While that can be true - there is nowhere in the document a restriction or even a warning that this solution is aiming for short lived flows only and that users should be well aware about drastic nature of proposed mechanism to their established flows. In one of the companies I worked for average TCP flow duration was anywhere from 8-18 hours and it was a very drastic event for the user to loose it in the middle of the day. Various means where taken and applied to protect such sessions from any form of disconnects. I think we are shooting here with the wrong weapon to the target. Thx, R. On Thu, Jan 13, 2022 at 4:23 PM Linda Dunbar mailto:linda.dun...@futurewei.com>> wrote: Robert, Your link to Traefik adds more reasons why "Site index and preference" should be distributed by IGP: * Site index and preferences for a cluster of micro-service instances are rarely dynamically changed. Most of those values are configured. Therefore, the oscillation is minimal. * Flows among micro-services are very short. Put less requirements to flow affinity. * Linda From: Robert Raszuk mailto:rob...@raszuk.net>> Sent: Thursday, January 13, 2022 5:00 AM To: Gyan Mishra mailto:hayabusa...@gmail.com>> Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; Linda Dunbar mailto:linda.dun...@futurewei.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute And just to provide a sound alternative to the objective of this work. Please consider using Traefik - https://traefik.io/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftraefik.io%2F=04%7C01%7Clinda.dunbar%40futurewei.com%7Cfbe3a5ade67347b9110608d9d6b50687%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776895275516159%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=M0zh%2FGcSbGbsMSTtLumrJwqHpaLEeN2BNrAC
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
> and I agree that using the IGP/Flex Algo as you are proposing is a viable solution. Except that IGP usually does not run between application server and load balancer ... On Thu, Jan 13, 2022 at 5:37 PM Les Ginsberg (ginsberg) wrote: > Linda – > > > > Are you saying that the scenario you are trying to address is to have a > given “transaction” go to the currently closest/most lightly loaded > Application Server? > > And there is no intent to support for long lived connections? > > > > If so, then this isn’t really a load balancing issue and I agree that > using the IGP/Flex Algo as you are proposing is a viable solution. > > The concern then becomes the rate of updates to the new Prefix Metric. If > this changes too rapidly this will heavily consume network resources by > triggering flooding, SPF, forwarding plane updates at a high rate. > > Can you put some language in the draft that indicates the expected rate of > updates to the metric and some guidelines on limiting the frequency? > > > > Thanx. > > > >Les > > > > > > *From:* Linda Dunbar > *Sent:* Thursday, January 13, 2022 7:58 AM > *To:* Robert Raszuk > *Cc:* Gyan Mishra ; Les Ginsberg (ginsberg) < > ginsb...@cisco.com>; lsr@ietf.org > *Subject:* RE: [Lsr] Seeking feedback to the revised > draft-dunbar-lsr-5g-edge-compute > > > > Robert, > > > > For your scenario of TCP flows lasting more than 8~18 hours, multiple > server instances SHOULDN’T be assigned with the SAME IP address (ANYCAST > address). Each of those instances should have one distinct IP address. > > > > The draft is for different scenario where application are instantiated at > multiple locations behind multiple App Layer Load Balancers. They have > relative short flows that can go to any App Layer Load Balancers. Multiple > Load Balancers for those applications are assigned with the same IP > address. In Kubernetes, multiple load balancers for one type of > microservices are assigned with one single Virtual IP address, so that the > network can forward as one single destination. > > > > Linda > > *From:* Robert Raszuk > *Sent:* Thursday, January 13, 2022 9:37 AM > *To:* Linda Dunbar > *Cc:* Gyan Mishra ; Les Ginsberg (ginsberg) < > ginsb...@cisco.com>; lsr@ietf.org > *Subject:* Re: [Lsr] Seeking feedback to the revised > draft-dunbar-lsr-5g-edge-compute > > > > > > > Flows among micro-services are very short. > > > > While that can be true - there is nowhere in the document a restriction or > even a warning that this solution is aiming for short lived flows only and > that users should be well aware about drastic nature of proposed > mechanism to their established flows. > > > > In one of the companies I worked for average TCP flow duration was > anywhere from 8-18 hours and it was a very drastic event for the user to > loose it in the middle of the day. Various means where taken and applied > to protect such sessions from any form of disconnects. > > > > I think we are shooting here with the wrong weapon to the target. > > > > Thx, > > R. > > > > On Thu, Jan 13, 2022 at 4:23 PM Linda Dunbar > wrote: > > Robert, > > > > Your link to Traefik adds more reasons why “Site index and preference” > should be distributed by IGP: > >- Site index and preferences for a cluster of micro-service instances >are rarely dynamically changed. Most of those values are configured. > Therefore, the oscillation is minimal. > - Flows among micro-services are very short. Put less requirements to >flow affinity. >- > > > > Linda > > > > > > *From:* Robert Raszuk > *Sent:* Thursday, January 13, 2022 5:00 AM > *To:* Gyan Mishra > *Cc:* Les Ginsberg (ginsberg) ; Linda Dunbar < > linda.dun...@futurewei.com>; lsr@ietf.org > *Subject:* Re: [Lsr] Seeking feedback to the revised > draft-dunbar-lsr-5g-edge-compute > > > > > > And just to provide a sound alternative to the objective of this work. > > > > Please consider using Traefik - https://traefik.io/ > <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftraefik.io%2F=04%7C01%7Clinda.dunbar%40futurewei.com%7C4361a0b36c614fbf8e7908d9d6aa8b4b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776850245075888%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=P%2BItvofz3%2Bgg0KEMdfxe9MluMPkQ2v1jL8a1Q50rddo%3D=0> > > > > Thx, > > R. > > > > > > On Thu, Jan 13, 2022 at 11:56 AM Robert Raszuk wrote: > > Gyan, > > > > I see what the draft is tr
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Linda - Are you saying that the scenario you are trying to address is to have a given "transaction" go to the currently closest/most lightly loaded Application Server? And there is no intent to support for long lived connections? If so, then this isn't really a load balancing issue and I agree that using the IGP/Flex Algo as you are proposing is a viable solution. The concern then becomes the rate of updates to the new Prefix Metric. If this changes too rapidly this will heavily consume network resources by triggering flooding, SPF, forwarding plane updates at a high rate. Can you put some language in the draft that indicates the expected rate of updates to the metric and some guidelines on limiting the frequency? Thanx. Les From: Linda Dunbar Sent: Thursday, January 13, 2022 7:58 AM To: Robert Raszuk Cc: Gyan Mishra ; Les Ginsberg (ginsberg) ; lsr@ietf.org Subject: RE: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Robert, For your scenario of TCP flows lasting more than 8~18 hours, multiple server instances SHOULDN'T be assigned with the SAME IP address (ANYCAST address). Each of those instances should have one distinct IP address. The draft is for different scenario where application are instantiated at multiple locations behind multiple App Layer Load Balancers. They have relative short flows that can go to any App Layer Load Balancers. Multiple Load Balancers for those applications are assigned with the same IP address. In Kubernetes, multiple load balancers for one type of microservices are assigned with one single Virtual IP address, so that the network can forward as one single destination. Linda From: Robert Raszuk Sent: Thursday, January 13, 2022 9:37 AM To: Linda Dunbar Cc: Gyan Mishra ; Les Ginsberg (ginsberg) ; lsr@ietf.org Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute > Flows among micro-services are very short. While that can be true - there is nowhere in the document a restriction or even a warning that this solution is aiming for short lived flows only and that users should be well aware about drastic nature of proposed mechanism to their established flows. In one of the companies I worked for average TCP flow duration was anywhere from 8-18 hours and it was a very drastic event for the user to loose it in the middle of the day. Various means where taken and applied to protect such sessions from any form of disconnects. I think we are shooting here with the wrong weapon to the target. Thx, R. On Thu, Jan 13, 2022 at 4:23 PM Linda Dunbar mailto:linda.dun...@futurewei.com>> wrote: Robert, Your link to Traefik adds more reasons why "Site index and preference" should be distributed by IGP: * Site index and preferences for a cluster of micro-service instances are rarely dynamically changed. Most of those values are configured. Therefore, the oscillation is minimal. * Flows among micro-services are very short. Put less requirements to flow affinity. * Linda From: Robert Raszuk mailto:rob...@raszuk.net>> Sent: Thursday, January 13, 2022 5:00 AM To: Gyan Mishra mailto:hayabusa...@gmail.com>> Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; Linda Dunbar mailto:linda.dun...@futurewei.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute And just to provide a sound alternative to the objective of this work. Please consider using Traefik - https://traefik.io/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftraefik.io%2F=04%7C01%7Clinda.dunbar%40futurewei.com%7C4361a0b36c614fbf8e7908d9d6aa8b4b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776850245075888%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=P%2BItvofz3%2Bgg0KEMdfxe9MluMPkQ2v1jL8a1Q50rddo%3D=0> Thx, R. On Thu, Jan 13, 2022 at 11:56 AM Robert Raszuk mailto:rob...@raszuk.net>> wrote: Gyan, I see what the draft is trying to do now. /* I did not even consider this for the reason described below. */ But what you wrote requires little correction: "So now the server you are on gets overloaded and a site cost gets advertised in the IGP at which point the connection receives a TCP reset" if you s/connection/all connections/ then you quickly realize that what is proposed here is a disaster. Breaking all existing flows going to one LB to suddenly timeout and all go to the other LB(s) is never a technique any one would seriously deploy in a production network. Leave alone that doing that has potential to immediately overload the other LB(s)/server(s) too. For me the conclusion is that IGP transport level is not the proper layer to address the requirement. Cheers, Robert. On Thu, Jan 13, 2022 at 7:05 AM Gyan Mishra mailto:hayabusa...@gmail.com>> wrote: Hi
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Robert, For your scenario of TCP flows lasting more than 8~18 hours, multiple server instances SHOULDN'T be assigned with the SAME IP address (ANYCAST address). Each of those instances should have one distinct IP address. The draft is for different scenario where application are instantiated at multiple locations behind multiple App Layer Load Balancers. They have relative short flows that can go to any App Layer Load Balancers. Multiple Load Balancers for those applications are assigned with the same IP address. In Kubernetes, multiple load balancers for one type of microservices are assigned with one single Virtual IP address, so that the network can forward as one single destination. Linda From: Robert Raszuk Sent: Thursday, January 13, 2022 9:37 AM To: Linda Dunbar Cc: Gyan Mishra ; Les Ginsberg (ginsberg) ; lsr@ietf.org Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute > Flows among micro-services are very short. While that can be true - there is nowhere in the document a restriction or even a warning that this solution is aiming for short lived flows only and that users should be well aware about drastic nature of proposed mechanism to their established flows. In one of the companies I worked for average TCP flow duration was anywhere from 8-18 hours and it was a very drastic event for the user to loose it in the middle of the day. Various means where taken and applied to protect such sessions from any form of disconnects. I think we are shooting here with the wrong weapon to the target. Thx, R. On Thu, Jan 13, 2022 at 4:23 PM Linda Dunbar mailto:linda.dun...@futurewei.com>> wrote: Robert, Your link to Traefik adds more reasons why "Site index and preference" should be distributed by IGP: * Site index and preferences for a cluster of micro-service instances are rarely dynamically changed. Most of those values are configured. Therefore, the oscillation is minimal. * Flows among micro-services are very short. Put less requirements to flow affinity. * Linda From: Robert Raszuk mailto:rob...@raszuk.net>> Sent: Thursday, January 13, 2022 5:00 AM To: Gyan Mishra mailto:hayabusa...@gmail.com>> Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; Linda Dunbar mailto:linda.dun...@futurewei.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute And just to provide a sound alternative to the objective of this work. Please consider using Traefik - https://traefik.io/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftraefik.io%2F=04%7C01%7Clinda.dunbar%40futurewei.com%7C4361a0b36c614fbf8e7908d9d6aa8b4b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776850245075888%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=P%2BItvofz3%2Bgg0KEMdfxe9MluMPkQ2v1jL8a1Q50rddo%3D=0> Thx, R. On Thu, Jan 13, 2022 at 11:56 AM Robert Raszuk mailto:rob...@raszuk.net>> wrote: Gyan, I see what the draft is trying to do now. /* I did not even consider this for the reason described below. */ But what you wrote requires little correction: "So now the server you are on gets overloaded and a site cost gets advertised in the IGP at which point the connection receives a TCP reset" if you s/connection/all connections/ then you quickly realize that what is proposed here is a disaster. Breaking all existing flows going to one LB to suddenly timeout and all go to the other LB(s) is never a technique any one would seriously deploy in a production network. Leave alone that doing that has potential to immediately overload the other LB(s)/server(s) too. For me the conclusion is that IGP transport level is not the proper layer to address the requirement. Cheers, Robert. On Thu, Jan 13, 2022 at 7:05 AM Gyan Mishra mailto:hayabusa...@gmail.com>> wrote: Hi Les Agreed. My thoughts are that the context of the draft is based on an Anycast VIP address of a server which is proximity based load balancing and not necessarily ECMP/UCMP and only if the proximity is the same for multiple paths to the Anycast VIP would there be a ECMP/UCMP possibility. Let's say if it's proximity based and one path is preferred, the flow will take that path. So now the server you are on gets overloaded and a site cost gets advertised in the IGP at which point the connection receives a TCP reset and flow re-establishes on the alternate path based on the site cost and remains there until the server goes down or gets overloaded or a better path comes along. For ECMP case, ECMP has flow affinity so the flow will stay on the same path long lived until the connection terminates. So now in ECMP case the flow hashed to a path and maintains its affinity to that path. Now all of sudden the server gets overloaded and we get a better site cos
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
> Flows among micro-services are very short. While that can be true - there is nowhere in the document a restriction or even a warning that this solution is aiming for short lived flows only and that users should be well aware about drastic nature of proposed mechanism to their established flows. In one of the companies I worked for average TCP flow duration was anywhere from 8-18 hours and it was a very drastic event for the user to loose it in the middle of the day. Various means where taken and applied to protect such sessions from any form of disconnects. I think we are shooting here with the wrong weapon to the target. Thx, R. On Thu, Jan 13, 2022 at 4:23 PM Linda Dunbar wrote: > Robert, > > > > Your link to Traefik adds more reasons why “Site index and preference” > should be distributed by IGP: > >- Site index and preferences for a cluster of micro-service instances >are rarely dynamically changed. Most of those values are configured. >Therefore, the oscillation is minimal. >- Flows among micro-services are very short. Put less requirements to >flow affinity. >- > > > > Linda > > > > > > *From:* Robert Raszuk > *Sent:* Thursday, January 13, 2022 5:00 AM > *To:* Gyan Mishra > *Cc:* Les Ginsberg (ginsberg) ; Linda Dunbar < > linda.dun...@futurewei.com>; lsr@ietf.org > *Subject:* Re: [Lsr] Seeking feedback to the revised > draft-dunbar-lsr-5g-edge-compute > > > > > > And just to provide a sound alternative to the objective of this work. > > > > Please consider using Traefik - https://traefik.io/ > <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftraefik.io%2F=04%7C01%7Clinda.dunbar%40futurewei.com%7Cb7985d17f6cf4691516c08d9d683cb4c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776683827234342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=DTSgF4GOdBXmJmF18s%2BhPYpod1g2wul6z%2BY6Gi6a%2F14%3D=0> > > > > Thx, > > R. > > > > > > On Thu, Jan 13, 2022 at 11:56 AM Robert Raszuk wrote: > > Gyan, > > > > I see what the draft is trying to do now. /* I did not even consider this > for the reason described below. */ > > > > But what you wrote requires little correction: > > > > "So now the server you are on gets overloaded and a site cost gets > advertised in the IGP at which point the connection receives a TCP reset" > > > > if you *s/connection/all connections/* then you quickly realize that what > is proposed here is a disaster. > > > > Breaking all existing flows going to one LB to suddenly timeout and all go > to the other LB(s) is never a technique any one would seriously deploy in a > production network. > > > > Leave alone that doing that has potential to immediately overload the > other LB(s)/server(s) too. > > > > For me the conclusion is that IGP transport level is not the proper layer > to address the requirement. > > > > Cheers, > > Robert. > > > > > > On Thu, Jan 13, 2022 at 7:05 AM Gyan Mishra wrote: > > > > Hi Les > > > > Agreed. > > > > My thoughts are that the context of the draft is based on an Anycast VIP > address of a server which is proximity based load balancing and not > necessarily ECMP/UCMP and only if the proximity is the same for multiple > paths to the Anycast VIP would there be a ECMP/UCMP possibility. > > > > Let’s say if it’s proximity based and one path is preferred, the flow will > take that path. So now the server you are on gets overloaded and a site > cost gets advertised in the IGP at which point the connection receives a > TCP reset and flow re-establishes on the alternate path based on the site > cost and remains there until the server goes down or gets overloaded or a > better path comes along. > > > > For ECMP case, ECMP has flow affinity so the flow will stay on the same > path long lived until the connection terminates. > > > > So now in ECMP case the flow hashed to a path and maintains its affinity > to that path. Now all of sudden the server gets overloaded and we get a > better site cost advertised. So now the session terminates on current path > and establishes again on the Anycast VIP new path based on the site cost > advertised. > > > > The failover I believe results in the user refreshing their browser which > is better than hanging. > > > > As the VIP prefix is the only one that experiences reconvergence on new > path based on site cost if there is any instability with the servers that > will be reflected to the IGP Anycast prefix as well. > > > > Is that a good or bad thi
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Robert, Your link to Traefik adds more reasons why "Site index and preference" should be distributed by IGP: * Site index and preferences for a cluster of micro-service instances are rarely dynamically changed. Most of those values are configured. Therefore, the oscillation is minimal. * Flows among micro-services are very short. Put less requirements to flow affinity. * Linda From: Robert Raszuk Sent: Thursday, January 13, 2022 5:00 AM To: Gyan Mishra Cc: Les Ginsberg (ginsberg) ; Linda Dunbar ; lsr@ietf.org Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute And just to provide a sound alternative to the objective of this work. Please consider using Traefik - https://traefik.io/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftraefik.io%2F=04%7C01%7Clinda.dunbar%40futurewei.com%7Cb7985d17f6cf4691516c08d9d683cb4c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776683827234342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=DTSgF4GOdBXmJmF18s%2BhPYpod1g2wul6z%2BY6Gi6a%2F14%3D=0> Thx, R. On Thu, Jan 13, 2022 at 11:56 AM Robert Raszuk mailto:rob...@raszuk.net>> wrote: Gyan, I see what the draft is trying to do now. /* I did not even consider this for the reason described below. */ But what you wrote requires little correction: "So now the server you are on gets overloaded and a site cost gets advertised in the IGP at which point the connection receives a TCP reset" if you s/connection/all connections/ then you quickly realize that what is proposed here is a disaster. Breaking all existing flows going to one LB to suddenly timeout and all go to the other LB(s) is never a technique any one would seriously deploy in a production network. Leave alone that doing that has potential to immediately overload the other LB(s)/server(s) too. For me the conclusion is that IGP transport level is not the proper layer to address the requirement. Cheers, Robert. On Thu, Jan 13, 2022 at 7:05 AM Gyan Mishra mailto:hayabusa...@gmail.com>> wrote: Hi Les Agreed. My thoughts are that the context of the draft is based on an Anycast VIP address of a server which is proximity based load balancing and not necessarily ECMP/UCMP and only if the proximity is the same for multiple paths to the Anycast VIP would there be a ECMP/UCMP possibility. Let's say if it's proximity based and one path is preferred, the flow will take that path. So now the server you are on gets overloaded and a site cost gets advertised in the IGP at which point the connection receives a TCP reset and flow re-establishes on the alternate path based on the site cost and remains there until the server goes down or gets overloaded or a better path comes along. For ECMP case, ECMP has flow affinity so the flow will stay on the same path long lived until the connection terminates. So now in ECMP case the flow hashed to a path and maintains its affinity to that path. Now all of sudden the server gets overloaded and we get a better site cost advertised. So now the session terminates on current path and establishes again on the Anycast VIP new path based on the site cost advertised. The failover I believe results in the user refreshing their browser which is better than hanging. As the VIP prefix is the only one that experiences reconvergence on new path based on site cost if there is any instability with the servers that will be reflected to the IGP Anycast prefix as well. Is that a good or bad thing. I think if you had to pick your poison as here the issue Linda is trying to solve is a server issue but leveraging the IGP to force re-convergence when the server is in a half baked state meaning it's busy and connections are being dropped or very slow QOE for end user. If you did nothing and let it ride the the user would be stuck on a bad connection. So this solution dynamically fixed the issue. As far as oscillation that is not a big deal as you are in a much worse off state connected to a dying server on its last leg as far as memory and CPU. This solution I can see can apply to any client / server connection and not just 5G and can be used by enterprises as well as SP for their customers to have an drastically improved QOE. I saw some feedback on the TLV and I think once that is all worked out I am in favor of advancing this draft. Kind Regards Gyan On Wed, Jan 12, 2022 at 10:16 PM Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>> wrote: Gyan - The difference between ECMP and UCMP is not significant in this discussion. I don't want to speak for Robert, but for me his point was that IGPs can do "multipath" well - but this does not translate into managing flows. Please see my other responses on this thread. Thanx. Les From: Gyan Mishra mailto:hayabusa...@gmail.com>> Sent: Wednesday, January 12, 2022
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
And just to provide a sound alternative to the objective of this work. Please consider using Traefik - https://traefik.io/ Thx, R. On Thu, Jan 13, 2022 at 11:56 AM Robert Raszuk wrote: > Gyan, > > I see what the draft is trying to do now. /* I did not even consider this > for the reason described below. */ > > But what you wrote requires little correction: > > "So now the server you are on gets overloaded and a site cost gets > advertised in the IGP at which point the connection receives a TCP reset" > > if you *s/connection/all connections/* then you quickly realize that what > is proposed here is a disaster. > > Breaking all existing flows going to one LB to suddenly timeout and all go > to the other LB(s) is never a technique any one would seriously deploy in a > production network. > > Leave alone that doing that has potential to immediately overload the > other LB(s)/server(s) too. > > For me the conclusion is that IGP transport level is not the proper layer > to address the requirement. > > Cheers, > Robert. > > > On Thu, Jan 13, 2022 at 7:05 AM Gyan Mishra wrote: > >> >> Hi Les >> >> Agreed. >> >> My thoughts are that the context of the draft is based on an Anycast VIP >> address of a server which is proximity based load balancing and not >> necessarily ECMP/UCMP and only if the proximity is the same for multiple >> paths to the Anycast VIP would there be a ECMP/UCMP possibility. >> >> Let’s say if it’s proximity based and one path is preferred, the flow >> will take that path. So now the server you are on gets overloaded and a >> site cost gets advertised in the IGP at which point the connection receives >> a TCP reset and flow re-establishes on the alternate path based on the site >> cost and remains there until the server goes down or gets overloaded or a >> better path comes along. >> >> For ECMP case, ECMP has flow affinity so the flow will stay on the same >> path long lived until the connection terminates. >> >> So now in ECMP case the flow hashed to a path and maintains its affinity >> to that path. Now all of sudden the server gets overloaded and we get a >> better site cost advertised. So now the session terminates on current path >> and establishes again on the Anycast VIP new path based on the site cost >> advertised. >> >> The failover I believe results in the user refreshing their browser which >> is better than hanging. >> >> As the VIP prefix is the only one that experiences reconvergence on new >> path based on site cost if there is any instability with the servers that >> will be reflected to the IGP Anycast prefix as well. >> >> Is that a good or bad thing. I think if you had to pick your poison as >> here the issue Linda is trying to solve is a server issue but leveraging >> the IGP to force re-convergence when the server is in a half baked state >> meaning it’s busy and connections are being dropped or very slow QOE for >> end user. If you did nothing and let it ride the the user would be stuck >> on a bad connection. >> >> So this solution dynamically fixed the issue. >> >> As far as oscillation that is not a big deal as you are in a much worse >> off state connected to a dying server on its last leg as far as memory and >> CPU. >> >> This solution I can see can apply to any client / server connection and >> not just 5G and can be used by enterprises as well as SP for their >> customers to have an drastically improved QOE. >> >> I saw some feedback on the TLV and I think once that is all worked out I >> am in favor of advancing this draft. >> >> Kind Regards >> >> Gyan >> >> >> On Wed, Jan 12, 2022 at 10:16 PM Les Ginsberg (ginsberg) < >> ginsb...@cisco.com> wrote: >> >>> Gyan – >>> >>> >>> >>> The difference between ECMP and UCMP is not significant in this >>> discussion. >>> >>> I don’t want to speak for Robert, but for me his point was that IGPs can >>> do “multipath” well – but this does not translate into managing flows. >>> >>> Please see my other responses on this thread. >>> >>> >>> >>> Thanx. >>> >>> >>> >>> Les >>> >>> >>> >>> >>> >>> *From:* Gyan Mishra >>> *Sent:* Wednesday, January 12, 2022 5:26 PM >>> *To:* Robert Raszuk >>> *Cc:* Les Ginsberg (ginsberg) ; Linda Dunbar < >>> linda.dun...@futurewei.com>; lsr@ietf.org >&
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Gyan, I see what the draft is trying to do now. /* I did not even consider this for the reason described below. */ But what you wrote requires little correction: "So now the server you are on gets overloaded and a site cost gets advertised in the IGP at which point the connection receives a TCP reset" if you *s/connection/all connections/* then you quickly realize that what is proposed here is a disaster. Breaking all existing flows going to one LB to suddenly timeout and all go to the other LB(s) is never a technique any one would seriously deploy in a production network. Leave alone that doing that has potential to immediately overload the other LB(s)/server(s) too. For me the conclusion is that IGP transport level is not the proper layer to address the requirement. Cheers, Robert. On Thu, Jan 13, 2022 at 7:05 AM Gyan Mishra wrote: > > Hi Les > > Agreed. > > My thoughts are that the context of the draft is based on an Anycast VIP > address of a server which is proximity based load balancing and not > necessarily ECMP/UCMP and only if the proximity is the same for multiple > paths to the Anycast VIP would there be a ECMP/UCMP possibility. > > Let’s say if it’s proximity based and one path is preferred, the flow will > take that path. So now the server you are on gets overloaded and a site > cost gets advertised in the IGP at which point the connection receives a > TCP reset and flow re-establishes on the alternate path based on the site > cost and remains there until the server goes down or gets overloaded or a > better path comes along. > > For ECMP case, ECMP has flow affinity so the flow will stay on the same > path long lived until the connection terminates. > > So now in ECMP case the flow hashed to a path and maintains its affinity > to that path. Now all of sudden the server gets overloaded and we get a > better site cost advertised. So now the session terminates on current path > and establishes again on the Anycast VIP new path based on the site cost > advertised. > > The failover I believe results in the user refreshing their browser which > is better than hanging. > > As the VIP prefix is the only one that experiences reconvergence on new > path based on site cost if there is any instability with the servers that > will be reflected to the IGP Anycast prefix as well. > > Is that a good or bad thing. I think if you had to pick your poison as > here the issue Linda is trying to solve is a server issue but leveraging > the IGP to force re-convergence when the server is in a half baked state > meaning it’s busy and connections are being dropped or very slow QOE for > end user. If you did nothing and let it ride the the user would be stuck > on a bad connection. > > So this solution dynamically fixed the issue. > > As far as oscillation that is not a big deal as you are in a much worse > off state connected to a dying server on its last leg as far as memory and > CPU. > > This solution I can see can apply to any client / server connection and > not just 5G and can be used by enterprises as well as SP for their > customers to have an drastically improved QOE. > > I saw some feedback on the TLV and I think once that is all worked out I > am in favor of advancing this draft. > > Kind Regards > > Gyan > > > On Wed, Jan 12, 2022 at 10:16 PM Les Ginsberg (ginsberg) < > ginsb...@cisco.com> wrote: > >> Gyan – >> >> >> >> The difference between ECMP and UCMP is not significant in this >> discussion. >> >> I don’t want to speak for Robert, but for me his point was that IGPs can >> do “multipath” well – but this does not translate into managing flows. >> >> Please see my other responses on this thread. >> >> >> >> Thanx. >> >> >> >> Les >> >> >> >> >> >> *From:* Gyan Mishra >> *Sent:* Wednesday, January 12, 2022 5:26 PM >> *To:* Robert Raszuk >> *Cc:* Les Ginsberg (ginsberg) ; Linda Dunbar < >> linda.dun...@futurewei.com>; lsr@ietf.org >> *Subject:* Re: [Lsr] Seeking feedback to the revised >> draft-dunbar-lsr-5g-edge-compute >> >> >> >> >> >> Robert >> >> >> >> Here are a few examples of UCMP drafts below used in core and data center >> use cases. >> >> >> >> https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-unequal-lb-15 >> >> >> >> https://datatracker.ietf.org/doc/html/draft-mohanty-bess-weighted-hrw-02 >> >> >> >> https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth >> >> >> >> https://datatracker.ietf.org/doc
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Gyan, Your below email nicely proves my point. Unequal cost load sharing is done at the app level not IGP transport. Thank you, R. On Thu, Jan 13, 2022 at 2:26 AM Gyan Mishra wrote: > > Robert > > Here are a few examples of UCMP drafts below used in core and data center > use cases. > > https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-unequal-lb-15 > > https://datatracker.ietf.org/doc/html/draft-mohanty-bess-weighted-hrw-02 > > https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth > > https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz > > > > There are many use cases in routing for unequal cost load balancing > capabilities. > > Kind Regards > > Gyan > > On Wed, Jan 12, 2022 at 2:23 PM Robert Raszuk wrote: > >> Linda, >> >> > IGP has been used for the Multi-path computation for a long time >> >> IGP can and does ECMP well. Moreover, injecting metric of anycast server >> destination plays no role in it as all paths would inherit that external to >> the IGP cost. >> >> Unequal cost load balancing or intelligent traffic spread has always been >> done at the application layer *for example MPLS* >> >> Thx a lot, >> R. >> >> On Wed, Jan 12, 2022 at 8:18 PM Linda Dunbar >> wrote: >> >>> Robert, >>> >>> >>> >>> Please see inline in green: >>> >>> >>> >>> *From:* Robert Raszuk >>> *Sent:* Wednesday, January 12, 2022 1:00 PM >>> *To:* Linda Dunbar >>> *Cc:* Les Ginsberg (ginsberg) ; lsr@ietf.org >>> *Subject:* Re: [Lsr] Seeking feedback to the revised >>> draft-dunbar-lsr-5g-edge-compute >>> >>> >>> >>> Hi Linda, >>> >>> >>> >>> *[LES:] It is my opinion that what you propose will not achieve your >>> goals – in part because IGPs only influence forwarding on a per packet >>> basis – not a per flow/connection basis.* >>> >>> *[Linda] Most vendors do support flow based ECMP, with Shortest Path >>> computed by attributes advertised by IGP.* >>> >>> >>> >>> I am with Les here. ECMP has nothing to do with his point. >>> >>> >>> >>> [Linda] Les said that “IGP only influence forwarding on a per packet >>> basis”. I am saying that vendors supporting “forwarding per flow” with >>> equal cost computed by IGP implies that forwarding on modern routers are >>> no longer purely per packet basis. >>> >>> >>> >>> >>> >>> Draft says: >>> >>> >>> >>> *When those multiple server instances share one IP address (ANYCAST), >>> the transient network and load conditions can be incorporated in selecting >>> an optimal path among server instances for UEs.* >>> >>> >>> >>> So if we apply any new metric to indicate load of a single anycast >>> address how is this going to help anything ? >>> >>> >>> >>> [Linda] The “Load” or “Aggregated Site Cost” is to differentiate >>> multiple paths with the same routing distance. >>> >>> >>> >>> >>> >>> You would need a mechanism where the network is smart and say per >>> src-dst tuple or more spreads the traffic. IGP does not play that game >>> today I am afraid. >>> >>> [Linda] There is one SRC and multiple paths to one DST. IGP has been >>> used for the Multi-path computation for a long time. >>> >>> >>> >>> Thank you, Linda >>> >>> >>> >>> Thx a lot, >>> R. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> ___ >> Lsr mailing list >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr >> > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > *Email gyan.s.mis...@verizon.com * > > > > *M 301 502-1347* > > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Hi Les Agreed. My thoughts are that the context of the draft is based on an Anycast VIP address of a server which is proximity based load balancing and not necessarily ECMP/UCMP and only if the proximity is the same for multiple paths to the Anycast VIP would there be a ECMP/UCMP possibility. Let’s say if it’s proximity based and one path is preferred, the flow will take that path. So now the server you are on gets overloaded and a site cost gets advertised in the IGP at which point the connection receives a TCP reset and flow re-establishes on the alternate path based on the site cost and remains there until the server goes down or gets overloaded or a better path comes along. For ECMP case, ECMP has flow affinity so the flow will stay on the same path long lived until the connection terminates. So now in ECMP case the flow hashed to a path and maintains its affinity to that path. Now all of sudden the server gets overloaded and we get a better site cost advertised. So now the session terminates on current path and establishes again on the Anycast VIP new path based on the site cost advertised. The failover I believe results in the user refreshing their browser which is better than hanging. As the VIP prefix is the only one that experiences reconvergence on new path based on site cost if there is any instability with the servers that will be reflected to the IGP Anycast prefix as well. Is that a good or bad thing. I think if you had to pick your poison as here the issue Linda is trying to solve is a server issue but leveraging the IGP to force re-convergence when the server is in a half baked state meaning it’s busy and connections are being dropped or very slow QOE for end user. If you did nothing and let it ride the the user would be stuck on a bad connection. So this solution dynamically fixed the issue. As far as oscillation that is not a big deal as you are in a much worse off state connected to a dying server on its last leg as far as memory and CPU. This solution I can see can apply to any client / server connection and not just 5G and can be used by enterprises as well as SP for their customers to have an drastically improved QOE. I saw some feedback on the TLV and I think once that is all worked out I am in favor of advancing this draft. Kind Regards Gyan On Wed, Jan 12, 2022 at 10:16 PM Les Ginsberg (ginsberg) wrote: > Gyan – > > > > The difference between ECMP and UCMP is not significant in this discussion. > > I don’t want to speak for Robert, but for me his point was that IGPs can > do “multipath” well – but this does not translate into managing flows. > > Please see my other responses on this thread. > > > > Thanx. > > > > Les > > > > > > *From:* Gyan Mishra > *Sent:* Wednesday, January 12, 2022 5:26 PM > *To:* Robert Raszuk > *Cc:* Les Ginsberg (ginsberg) ; Linda Dunbar < > linda.dun...@futurewei.com>; lsr@ietf.org > *Subject:* Re: [Lsr] Seeking feedback to the revised > draft-dunbar-lsr-5g-edge-compute > > > > > > Robert > > > > Here are a few examples of UCMP drafts below used in core and data center > use cases. > > > > https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-unequal-lb-15 > > > > https://datatracker.ietf.org/doc/html/draft-mohanty-bess-weighted-hrw-02 > > > > https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth > > > > https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz > > > > > > > > There are many use cases in routing for unequal cost load balancing > capabilities. > > > > Kind Regards > > > > Gyan > > > > On Wed, Jan 12, 2022 at 2:23 PM Robert Raszuk wrote: > > Linda, > > > > > IGP has been used for the Multi-path computation for a long time > > > > IGP can and does ECMP well. Moreover, injecting metric of anycast server > destination plays no role in it as all paths would inherit that external to > the IGP cost. > > > > Unequal cost load balancing or intelligent traffic spread has always been > done at the application layer *for example MPLS* > > > > Thx a lot, > > R. > > > > On Wed, Jan 12, 2022 at 8:18 PM Linda Dunbar > wrote: > > Robert, > > > > Please see inline in green: > > > > *From:* Robert Raszuk > *Sent:* Wednesday, January 12, 2022 1:00 PM > *To:* Linda Dunbar > *Cc:* Les Ginsberg (ginsberg) ; lsr@ietf.org > *Subject:* Re: [Lsr] Seeking feedback to the revised > draft-dunbar-lsr-5g-edge-compute > > > > Hi Linda, > > > > *[LES:] It is my opinion that what you propose will not achieve your goals > – in part because IGPs only influence forwarding on a per packet basis – > not a per flow/connec
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Gyan – The difference between ECMP and UCMP is not significant in this discussion. I don’t want to speak for Robert, but for me his point was that IGPs can do “multipath” well – but this does not translate into managing flows. Please see my other responses on this thread. Thanx. Les From: Gyan Mishra Sent: Wednesday, January 12, 2022 5:26 PM To: Robert Raszuk Cc: Les Ginsberg (ginsberg) ; Linda Dunbar ; lsr@ietf.org Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Robert Here are a few examples of UCMP drafts below used in core and data center use cases. https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-unequal-lb-15 https://datatracker.ietf.org/doc/html/draft-mohanty-bess-weighted-hrw-02 https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz There are many use cases in routing for unequal cost load balancing capabilities. Kind Regards Gyan On Wed, Jan 12, 2022 at 2:23 PM Robert Raszuk mailto:rob...@raszuk.net>> wrote: Linda, > IGP has been used for the Multi-path computation for a long time IGP can and does ECMP well. Moreover, injecting metric of anycast server destination plays no role in it as all paths would inherit that external to the IGP cost. Unequal cost load balancing or intelligent traffic spread has always been done at the application layer *for example MPLS* Thx a lot, R. On Wed, Jan 12, 2022 at 8:18 PM Linda Dunbar mailto:linda.dun...@futurewei.com>> wrote: Robert, Please see inline in green: From: Robert Raszuk mailto:rob...@raszuk.net>> Sent: Wednesday, January 12, 2022 1:00 PM To: Linda Dunbar mailto:linda.dun...@futurewei.com>> Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Hi Linda, [LES:] It is my opinion that what you propose will not achieve your goals – in part because IGPs only influence forwarding on a per packet basis – not a per flow/connection basis. [Linda] Most vendors do support flow based ECMP, with Shortest Path computed by attributes advertised by IGP. I am with Les here. ECMP has nothing to do with his point. [Linda] Les said that “IGP only influence forwarding on a per packet basis”. I am saying that vendors supporting “forwarding per flow” with equal cost computed by IGP implies that forwarding on modern routers are no longer purely per packet basis. Draft says: When those multiple server instances share one IP address (ANYCAST), the transient network and load conditions can be incorporated in selecting an optimal path among server instances for UEs. So if we apply any new metric to indicate load of a single anycast address how is this going to help anything ? [Linda] The “Load” or “Aggregated Site Cost” is to differentiate multiple paths with the same routing distance. You would need a mechanism where the network is smart and say per src-dst tuple or more spreads the traffic. IGP does not play that game today I am afraid. [Linda] There is one SRC and multiple paths to one DST. IGP has been used for the Multi-path computation for a long time. Thank you, Linda Thx a lot, R. ___ Lsr mailing list Lsr@ietf.org<mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr -- [Image removed by sender.]<http://www.verizon.com/> Gyan Mishra Network Solutions Architect Email gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com> M 301 502-1347 ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Robert Here are a few examples of UCMP drafts below used in core and data center use cases. https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-unequal-lb-15 https://datatracker.ietf.org/doc/html/draft-mohanty-bess-weighted-hrw-02 https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz There are many use cases in routing for unequal cost load balancing capabilities. Kind Regards Gyan On Wed, Jan 12, 2022 at 2:23 PM Robert Raszuk wrote: > Linda, > > > IGP has been used for the Multi-path computation for a long time > > IGP can and does ECMP well. Moreover, injecting metric of anycast server > destination plays no role in it as all paths would inherit that external to > the IGP cost. > > Unequal cost load balancing or intelligent traffic spread has always been > done at the application layer *for example MPLS* > > Thx a lot, > R. > > On Wed, Jan 12, 2022 at 8:18 PM Linda Dunbar > wrote: > >> Robert, >> >> >> >> Please see inline in green: >> >> >> >> *From:* Robert Raszuk >> *Sent:* Wednesday, January 12, 2022 1:00 PM >> *To:* Linda Dunbar >> *Cc:* Les Ginsberg (ginsberg) ; lsr@ietf.org >> *Subject:* Re: [Lsr] Seeking feedback to the revised >> draft-dunbar-lsr-5g-edge-compute >> >> >> >> Hi Linda, >> >> >> >> *[LES:] It is my opinion that what you propose will not achieve your >> goals – in part because IGPs only influence forwarding on a per packet >> basis – not a per flow/connection basis.* >> >> *[Linda] Most vendors do support flow based ECMP, with Shortest Path >> computed by attributes advertised by IGP.* >> >> >> >> I am with Les here. ECMP has nothing to do with his point. >> >> >> >> [Linda] Les said that “IGP only influence forwarding on a per packet >> basis”. I am saying that vendors supporting “forwarding per flow” with >> equal cost computed by IGP implies that forwarding on modern routers are >> no longer purely per packet basis. >> >> >> >> >> >> Draft says: >> >> >> >> *When those multiple server instances share one IP address (ANYCAST), the >> transient network and load conditions can be incorporated in selecting an >> optimal path among server instances for UEs.* >> >> >> >> So if we apply any new metric to indicate load of a single anycast >> address how is this going to help anything ? >> >> >> >> [Linda] The “Load” or “Aggregated Site Cost” is to differentiate multiple >> paths with the same routing distance. >> >> >> >> >> >> You would need a mechanism where the network is smart and say per src-dst >> tuple or more spreads the traffic. IGP does not play that game today I am >> afraid. >> >> [Linda] There is one SRC and multiple paths to one DST. IGP has been used >> for the Multi-path computation for a long time. >> >> >> >> Thank you, Linda >> >> >> >> Thx a lot, >> R. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Still use the Dijkstra shortest path algorithm. Just the cost to the destination includes more than the routing hops. Linda From: Robert Raszuk Sent: Wednesday, January 12, 2022 2:39 PM To: Linda Dunbar Cc: Les Ginsberg (ginsberg) ; lsr@ietf.org Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute > IGP cost typically is determined by comparing the preference, then the weight, > then the metric, and finally the metric2 of the two resolving routes. Are we sure we are on the same page here ? Are you describing some new yet to be defined algorithm or Dijkstra ? Thx, R. On Wed, Jan 12, 2022 at 9:36 PM Linda Dunbar mailto:linda.dun...@futurewei.com>> wrote: Robert, IGP cost typically is determined by comparing the preference, then the weight, then the metric, and finally the metric2 of the two resolving routes. The draft is to add another site-cost metric to the IGP computation. Using MPLS is too heavy. Linda From: Robert Raszuk mailto:rob...@raszuk.net>> Sent: Wednesday, January 12, 2022 1:23 PM To: Linda Dunbar mailto:linda.dun...@futurewei.com>> Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Linda, > IGP has been used for the Multi-path computation for a long time IGP can and does ECMP well. Moreover, injecting metric of anycast server destination plays no role in it as all paths would inherit that external to the IGP cost. Unequal cost load balancing or intelligent traffic spread has always been done at the application layer *for example MPLS* Thx a lot, R. On Wed, Jan 12, 2022 at 8:18 PM Linda Dunbar mailto:linda.dun...@futurewei.com>> wrote: Robert, Please see inline in green: From: Robert Raszuk mailto:rob...@raszuk.net>> Sent: Wednesday, January 12, 2022 1:00 PM To: Linda Dunbar mailto:linda.dun...@futurewei.com>> Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Hi Linda, [LES:] It is my opinion that what you propose will not achieve your goals – in part because IGPs only influence forwarding on a per packet basis – not a per flow/connection basis. [Linda] Most vendors do support flow based ECMP, with Shortest Path computed by attributes advertised by IGP. I am with Les here. ECMP has nothing to do with his point. [Linda] Les said that “IGP only influence forwarding on a per packet basis”. I am saying that vendors supporting “forwarding per flow” with equal cost computed by IGP implies that forwarding on modern routers are no longer purely per packet basis. Draft says: When those multiple server instances share one IP address (ANYCAST), the transient network and load conditions can be incorporated in selecting an optimal path among server instances for UEs. So if we apply any new metric to indicate load of a single anycast address how is this going to help anything ? [Linda] The “Load” or “Aggregated Site Cost” is to differentiate multiple paths with the same routing distance. You would need a mechanism where the network is smart and say per src-dst tuple or more spreads the traffic. IGP does not play that game today I am afraid. [Linda] There is one SRC and multiple paths to one DST. IGP has been used for the Multi-path computation for a long time. Thank you, Linda Thx a lot, R. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
> IGP cost typically is determined by comparing the preference, then the weight, > then the metric, and finally the metric2 of the two resolving routes. Are we sure we are on the same page here ? Are you describing some new yet to be defined algorithm or Dijkstra ? Thx, R. On Wed, Jan 12, 2022 at 9:36 PM Linda Dunbar wrote: > Robert, > > > > IGP cost typically is determined by comparing the preference, then the > weight, then the metric, and finally the metric2 of the two resolving > routes. > > The draft is to add another site-cost metric to the IGP computation. > > Using MPLS is too heavy. > > > > Linda > > > > *From:* Robert Raszuk > *Sent:* Wednesday, January 12, 2022 1:23 PM > *To:* Linda Dunbar > *Cc:* Les Ginsberg (ginsberg) ; lsr@ietf.org > *Subject:* Re: [Lsr] Seeking feedback to the revised > draft-dunbar-lsr-5g-edge-compute > > > > Linda, > > > > > IGP has been used for the Multi-path computation for a long time > > > > IGP can and does ECMP well. Moreover, injecting metric of anycast server > destination plays no role in it as all paths would inherit that external to > the IGP cost. > > > > Unequal cost load balancing or intelligent traffic spread has always been > done at the application layer *for example MPLS* > > > > Thx a lot, > > R. > > > > On Wed, Jan 12, 2022 at 8:18 PM Linda Dunbar > wrote: > > Robert, > > > > Please see inline in green: > > > > *From:* Robert Raszuk > *Sent:* Wednesday, January 12, 2022 1:00 PM > *To:* Linda Dunbar > *Cc:* Les Ginsberg (ginsberg) ; lsr@ietf.org > *Subject:* Re: [Lsr] Seeking feedback to the revised > draft-dunbar-lsr-5g-edge-compute > > > > Hi Linda, > > > > *[LES:] It is my opinion that what you propose will not achieve your goals > – in part because IGPs only influence forwarding on a per packet basis – > not a per flow/connection basis.* > > *[Linda] Most vendors do support flow based ECMP, with Shortest Path > computed by attributes advertised by IGP.* > > > > I am with Les here. ECMP has nothing to do with his point. > > > > [Linda] Les said that “IGP only influence forwarding on a per packet > basis”. I am saying that vendors supporting “forwarding per flow” with > equal cost computed by IGP implies that forwarding on modern routers are > no longer purely per packet basis. > > > > > > Draft says: > > > > *When those multiple server instances share one IP address (ANYCAST), the > transient network and load conditions can be incorporated in selecting an > optimal path among server instances for UEs.* > > > > So if we apply any new metric to indicate load of a single anycast address > how is this going to help anything ? > > > > [Linda] The “Load” or “Aggregated Site Cost” is to differentiate multiple > paths with the same routing distance. > > > > > > You would need a mechanism where the network is smart and say per src-dst > tuple or more spreads the traffic. IGP does not play that game today I am > afraid. > > [Linda] There is one SRC and multiple paths to one DST. IGP has been used > for the Multi-path computation for a long time. > > > > Thank you, Linda > > > > Thx a lot, > R. > > > > > > > > > > > > > > > > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Robert, IGP cost typically is determined by comparing the preference, then the weight, then the metric, and finally the metric2 of the two resolving routes. The draft is to add another site-cost metric to the IGP computation. Using MPLS is too heavy. Linda From: Robert Raszuk Sent: Wednesday, January 12, 2022 1:23 PM To: Linda Dunbar Cc: Les Ginsberg (ginsberg) ; lsr@ietf.org Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Linda, > IGP has been used for the Multi-path computation for a long time IGP can and does ECMP well. Moreover, injecting metric of anycast server destination plays no role in it as all paths would inherit that external to the IGP cost. Unequal cost load balancing or intelligent traffic spread has always been done at the application layer *for example MPLS* Thx a lot, R. On Wed, Jan 12, 2022 at 8:18 PM Linda Dunbar mailto:linda.dun...@futurewei.com>> wrote: Robert, Please see inline in green: From: Robert Raszuk mailto:rob...@raszuk.net>> Sent: Wednesday, January 12, 2022 1:00 PM To: Linda Dunbar mailto:linda.dun...@futurewei.com>> Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Hi Linda, [LES:] It is my opinion that what you propose will not achieve your goals – in part because IGPs only influence forwarding on a per packet basis – not a per flow/connection basis. [Linda] Most vendors do support flow based ECMP, with Shortest Path computed by attributes advertised by IGP. I am with Les here. ECMP has nothing to do with his point. [Linda] Les said that “IGP only influence forwarding on a per packet basis”. I am saying that vendors supporting “forwarding per flow” with equal cost computed by IGP implies that forwarding on modern routers are no longer purely per packet basis. Draft says: When those multiple server instances share one IP address (ANYCAST), the transient network and load conditions can be incorporated in selecting an optimal path among server instances for UEs. So if we apply any new metric to indicate load of a single anycast address how is this going to help anything ? [Linda] The “Load” or “Aggregated Site Cost” is to differentiate multiple paths with the same routing distance. You would need a mechanism where the network is smart and say per src-dst tuple or more spreads the traffic. IGP does not play that game today I am afraid. [Linda] There is one SRC and multiple paths to one DST. IGP has been used for the Multi-path computation for a long time. Thank you, Linda Thx a lot, R. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Linda – Inline. Look for LES2: From: Linda Dunbar Sent: Wednesday, January 12, 2022 10:48 AM To: Les Ginsberg (ginsberg) ; lsr@ietf.org Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Les, Please see my questions to your suggestions inserted below: Linda From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>> Sent: Wednesday, January 12, 2022 11:21 AM To: Linda Dunbar mailto:linda.dun...@futurewei.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Linda – Please see inline. From: Linda Dunbar mailto:linda.dun...@futurewei.com>> Sent: Wednesday, January 12, 2022 8:41 AM To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Les, With regard to what You said about “needing to do load balancing at the Application Layer – not at Layer 3”: Answer: Most deployments could have 10s, 100s, or even thousands of Application Layer load balancers. The proposed solution is to utilize network layer and resource capability information to balance the distribution of traffic among the Application Load balancers. The documents stated that the distribution behind the load balancers are out of the scope. With regard to what you said about “oscillation”: Answer: The rate of capability index changes is in terms of hours or days, more like the link failure that IGP is intended to distribute. Therefore, the oscillation is not the issue. [LES:] It is my opinion that what you propose will not achieve your goals – in part because IGPs only influence forwarding on a per packet basis – not a per flow/connection basis. [Linda] Most vendors do support flow based ECMP, with Shortest Path computed by attributes advertised by IGP. [LES2:] Robert has already made the relevant points. Yes – routers today support maintaining flows, but it is done by applying policy to select from a set of nexthops provided by the routing protocol. This allows you to maintain flows and to load balance. You want to build the policy into the IGP metric, but this provides no way to maintain a flow. I also don’t understand why you mention “link failure” when the discussion here is about load balancing across multiple Application Servers even when the underlying network is stable. [Linda] I meant to say topology changes caused by “Link failure” or others. [LES2:] I am only saying the behavior you want has nothing to do with topology changes. Of course, if an Application Server goes down/becomes unreachable forwarding state will change – but that isn’t relevant to the new behavior (load balancing based on Application server load) that you want. With regard to what you said about “incorrect TLV” Per IANA: TLV 128 is for IP Int. Reachability; TLV 130 is for IP Ex Address; and TLV 135 is for Extended IP reachability. Do you mean another TLV should be used instead of TLV 128/130/135? [LES:] You cannot put sub-TLVs into TLVs 128/130. These TLVs are “old style” TLVs which do not support sub-TLVs of any kind. The following TLVs would be relevant: Extended IP reachability (135) MT IP Reach (235) IPv6 IP Reach (236) MT IPv6 IP Reach (237) [Linda] Thank you for the suggestion. Are Extended IP reachability (135) and MT IP Reachability (235) equally good? [LES2:] TLVs 135 and 236 work for MTID #0. TLVs 235 and 237 work for non-zero MTIDs. Generally, any sub-TLV which is defined can be used in either TLV. Which TLV you actually use depends on the MTID used in your deployment. Les Please see https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-advertising-prefix-reachability Thank you. Linda For the AggCostSubTLV, yes, the prefix shouldn’t be there. It is now changed to be consistent with OSPF: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |AggCostSubTLV | Length| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AggCost to the App Server| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Aggregated cost Advertisement in IS-IS [LES:] Great – thanx. Les Any other issues? Linda From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>> Sent: Tuesday, January 11, 2022 11:14 PM To: Linda Dunbar mailto:linda.dun...@futurewei.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Linda - From: Linda Dunbar mailto:linda.dun...@futurewei.com>> Sent: Tuesday, January 11, 2022 7:47 PM To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: RE: Seeking feedback to the revised draft-dunba
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Linda, > IGP has been used for the Multi-path computation for a long time IGP can and does ECMP well. Moreover, injecting metric of anycast server destination plays no role in it as all paths would inherit that external to the IGP cost. Unequal cost load balancing or intelligent traffic spread has always been done at the application layer *for example MPLS* Thx a lot, R. On Wed, Jan 12, 2022 at 8:18 PM Linda Dunbar wrote: > Robert, > > > > Please see inline in green: > > > > *From:* Robert Raszuk > *Sent:* Wednesday, January 12, 2022 1:00 PM > *To:* Linda Dunbar > *Cc:* Les Ginsberg (ginsberg) ; lsr@ietf.org > *Subject:* Re: [Lsr] Seeking feedback to the revised > draft-dunbar-lsr-5g-edge-compute > > > > Hi Linda, > > > > *[LES:] It is my opinion that what you propose will not achieve your goals > – in part because IGPs only influence forwarding on a per packet basis – > not a per flow/connection basis.* > > *[Linda] Most vendors do support flow based ECMP, with Shortest Path > computed by attributes advertised by IGP.* > > > > I am with Les here. ECMP has nothing to do with his point. > > > > [Linda] Les said that “IGP only influence forwarding on a per packet > basis”. I am saying that vendors supporting “forwarding per flow” with > equal cost computed by IGP implies that forwarding on modern routers are > no longer purely per packet basis. > > > > > > Draft says: > > > > *When those multiple server instances share one IP address (ANYCAST), the > transient network and load conditions can be incorporated in selecting an > optimal path among server instances for UEs.* > > > > So if we apply any new metric to indicate load of a single anycast address > how is this going to help anything ? > > > > [Linda] The “Load” or “Aggregated Site Cost” is to differentiate multiple > paths with the same routing distance. > > > > > > You would need a mechanism where the network is smart and say per src-dst > tuple or more spreads the traffic. IGP does not play that game today I am > afraid. > > [Linda] There is one SRC and multiple paths to one DST. IGP has been used > for the Multi-path computation for a long time. > > > > Thank you, Linda > > > > Thx a lot, > R. > > > > > > > > > > > > > > > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Robert, Please see inline in green: From: Robert Raszuk Sent: Wednesday, January 12, 2022 1:00 PM To: Linda Dunbar Cc: Les Ginsberg (ginsberg) ; lsr@ietf.org Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Hi Linda, [LES:] It is my opinion that what you propose will not achieve your goals – in part because IGPs only influence forwarding on a per packet basis – not a per flow/connection basis. [Linda] Most vendors do support flow based ECMP, with Shortest Path computed by attributes advertised by IGP. I am with Les here. ECMP has nothing to do with his point. [Linda] Les said that “IGP only influence forwarding on a per packet basis”. I am saying that vendors supporting “forwarding per flow” with equal cost computed by IGP implies that forwarding on modern routers are no longer purely per packet basis. Draft says: When those multiple server instances share one IP address (ANYCAST), the transient network and load conditions can be incorporated in selecting an optimal path among server instances for UEs. So if we apply any new metric to indicate load of a single anycast address how is this going to help anything ? [Linda] The “Load” or “Aggregated Site Cost” is to differentiate multiple paths with the same routing distance. You would need a mechanism where the network is smart and say per src-dst tuple or more spreads the traffic. IGP does not play that game today I am afraid. [Linda] There is one SRC and multiple paths to one DST. IGP has been used for the Multi-path computation for a long time. Thank you, Linda Thx a lot, R. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Hi Linda, *[LES:] It is my opinion that what you propose will not achieve your goals > – in part because IGPs only influence forwarding on a per packet basis – > not a per flow/connection basis.* > > *[Linda] Most vendors do support flow based ECMP, with Shortest Path > computed by attributes advertised by IGP.* > I am with Les here. ECMP has nothing to do with his point. Draft says: *When those multiple server instances share one IP address (ANYCAST), the transient network and load conditions can be incorporated in selecting an optimal path among server instances for UEs.* So if we apply any new metric to indicate load of a single anycast address how is this going to help anything ? You would need a mechanism where the network is smart and say per src-dst tuple or more spreads the traffic. IGP does not play that game today I am afraid. Thx a lot, R. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Les, Please see my questions to your suggestions inserted below: Linda From: Les Ginsberg (ginsberg) Sent: Wednesday, January 12, 2022 11:21 AM To: Linda Dunbar ; lsr@ietf.org Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Linda – Please see inline. From: Linda Dunbar mailto:linda.dun...@futurewei.com>> Sent: Wednesday, January 12, 2022 8:41 AM To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Les, With regard to what You said about “needing to do load balancing at the Application Layer – not at Layer 3”: Answer: Most deployments could have 10s, 100s, or even thousands of Application Layer load balancers. The proposed solution is to utilize network layer and resource capability information to balance the distribution of traffic among the Application Load balancers. The documents stated that the distribution behind the load balancers are out of the scope. With regard to what you said about “oscillation”: Answer: The rate of capability index changes is in terms of hours or days, more like the link failure that IGP is intended to distribute. Therefore, the oscillation is not the issue. [LES:] It is my opinion that what you propose will not achieve your goals – in part because IGPs only influence forwarding on a per packet basis – not a per flow/connection basis. [Linda] Most vendors do support flow based ECMP, with Shortest Path computed by attributes advertised by IGP. I also don’t understand why you mention “link failure” when the discussion here is about load balancing across multiple Application Servers even when the underlying network is stable. [Linda] I meant to say topology changes caused by “Link failure” or others. With regard to what you said about “incorrect TLV” Per IANA: TLV 128 is for IP Int. Reachability; TLV 130 is for IP Ex Address; and TLV 135 is for Extended IP reachability. Do you mean another TLV should be used instead of TLV 128/130/135? [LES:] You cannot put sub-TLVs into TLVs 128/130. These TLVs are “old style” TLVs which do not support sub-TLVs of any kind. The following TLVs would be relevant: Extended IP reachability (135) MT IP Reach (235) IPv6 IP Reach (236) MT IPv6 IP Reach (237) [Linda] Thank you for the suggestion. Are Extended IP reachability (135) and MT IP Reachability (235) equally good? Please see https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-advertising-prefix-reachability Thank you. Linda For the AggCostSubTLV, yes, the prefix shouldn’t be there. It is now changed to be consistent with OSPF: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |AggCostSubTLV | Length| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AggCost to the App Server| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Aggregated cost Advertisement in IS-IS [LES:] Great – thanx. Les Any other issues? Linda From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>> Sent: Tuesday, January 11, 2022 11:14 PM To: Linda Dunbar mailto:linda.dun...@futurewei.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Linda - From: Linda Dunbar mailto:linda.dun...@futurewei.com>> Sent: Tuesday, January 11, 2022 7:47 PM To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Les, Starting with a clean slate: Problem: Most applications are instantiated at multiple locations to achieve optimal performance. Traditional shortest path to reach one single destination is making load balancers the bottleneck, or pushing the traffic management responsibility to DNS. From Underlay IP network perspective, connecting applications with instances instantiated at multiple locations is like having multiple Egress routers towards the same destination (ANYCAST). For example, to reach an application B instantiated at B1, B2, B3, which corresponds to egress ER1, ER2, ER3 respectively, the Shortest Path Computation need to include both routing distance and the resources attached to ER1, ER2, ER3. i.e. the cost in the ECMP (Equal Cost Multiple Path) should include both the routing distances and the resource cost. [LES:] What I am saying is that you need to do load balancing at the Application Layer – not at Layer 3. IGPs can provide you with paths to the set of Application servers that share the same anycast address – but dynamically manipulating the IGP metrics (even this new metric you propose) – will give you oscillation – not application server load
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Linda – Please see inline. From: Linda Dunbar Sent: Wednesday, January 12, 2022 8:41 AM To: Les Ginsberg (ginsberg) ; lsr@ietf.org Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Les, With regard to what You said about “needing to do load balancing at the Application Layer – not at Layer 3”: Answer: Most deployments could have 10s, 100s, or even thousands of Application Layer load balancers. The proposed solution is to utilize network layer and resource capability information to balance the distribution of traffic among the Application Load balancers. The documents stated that the distribution behind the load balancers are out of the scope. With regard to what you said about “oscillation”: Answer: The rate of capability index changes is in terms of hours or days, more like the link failure that IGP is intended to distribute. Therefore, the oscillation is not the issue. [LES:] It is my opinion that what you propose will not achieve your goals – in part because IGPs only influence forwarding on a per packet basis – not a per flow/connection basis. I also don’t understand why you mention “link failure” when the discussion here is about load balancing across multiple Application Servers even when the underlying network is stable. With regard to what you said about “incorrect TLV” Per IANA: TLV 128 is for IP Int. Reachability; TLV 130 is for IP Ex Address; and TLV 135 is for Extended IP reachability. Do you mean another TLV should be used instead of TLV 128/130/135? [LES:] You cannot put sub-TLVs into TLVs 128/130. These TLVs are “old style” TLVs which do not support sub-TLVs of any kind. The following TLVs would be relevant: Extended IP reachability (135) MT IP Reach (235) IPv6 IP Reach (236) MT IPv6 IP Reach (237) Please see https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-advertising-prefix-reachability For the AggCostSubTLV, yes, the prefix shouldn’t be there. It is now changed to be consistent with OSPF: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |AggCostSubTLV | Length| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AggCost to the App Server| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Aggregated cost Advertisement in IS-IS [LES:] Great – thanx. Les Any other issues? Linda From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>> Sent: Tuesday, January 11, 2022 11:14 PM To: Linda Dunbar mailto:linda.dun...@futurewei.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Linda - From: Linda Dunbar mailto:linda.dun...@futurewei.com>> Sent: Tuesday, January 11, 2022 7:47 PM To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Les, Starting with a clean slate: Problem: Most applications are instantiated at multiple locations to achieve optimal performance. Traditional shortest path to reach one single destination is making load balancers the bottleneck, or pushing the traffic management responsibility to DNS. From Underlay IP network perspective, connecting applications with instances instantiated at multiple locations is like having multiple Egress routers towards the same destination (ANYCAST). For example, to reach an application B instantiated at B1, B2, B3, which corresponds to egress ER1, ER2, ER3 respectively, the Shortest Path Computation need to include both routing distance and the resources attached to ER1, ER2, ER3. i.e. the cost in the ECMP (Equal Cost Multiple Path) should include both the routing distances and the resource cost. [LES:] What I am saying is that you need to do load balancing at the Application Layer – not at Layer 3. IGPs can provide you with paths to the set of Application servers that share the same anycast address – but dynamically manipulating the IGP metrics (even this new metric you propose) – will give you oscillation – not application server load balancing. Suggested solution: Using TLV 128 and 130 to carry the “aggregated site cost” (associated t the Egress router) is suggested by Peter Psenak (through the offline discussion prior to the IETF 112, see the attached email thread) There is only one sentence in the Section 6, which is per Peter’s suggestion: “Aggregated Cost appended to the IP Reachability TLV: 128, 130, or 135.” Why do you say it is a “mess”? I felt your words are more like personal attack than giving a constructive suggestion. [LES:] Apologies if you were offended – I did put a smiley in to try give it a light touch – but I should know better than to be so flippant in this context. My point is
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Les, With regard to what You said about “needing to do load balancing at the Application Layer – not at Layer 3”: Answer: Most deployments could have 10s, 100s, or even thousands of Application Layer load balancers. The proposed solution is to utilize network layer and resource capability information to balance the distribution of traffic among the Application Load balancers. The documents stated that the distribution behind the load balancers are out of the scope. With regard to what you said about “oscillation”: Answer: The rate of capability index changes is in terms of hours or days, more like the link failure that IGP is intended to distribute. Therefore, the oscillation is not the issue. With regard to what you said about “incorrect TLV” Per IANA: TLV 128 is for IP Int. Reachability; TLV 130 is for IP Ex Address; and TLV 135 is for Extended IP reachability. Do you mean another TLV should be used instead of TLV 128/130/135? For the AggCostSubTLV, yes, the prefix shouldn’t be there. It is now changed to be consistent with OSPF: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |AggCostSubTLV | Length| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AggCost to the App Server| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Aggregated cost Advertisement in IS-IS Any other issues? Linda From: Les Ginsberg (ginsberg) Sent: Tuesday, January 11, 2022 11:14 PM To: Linda Dunbar ; lsr@ietf.org Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Linda - From: Linda Dunbar mailto:linda.dun...@futurewei.com>> Sent: Tuesday, January 11, 2022 7:47 PM To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Les, Starting with a clean slate: Problem: Most applications are instantiated at multiple locations to achieve optimal performance. Traditional shortest path to reach one single destination is making load balancers the bottleneck, or pushing the traffic management responsibility to DNS. From Underlay IP network perspective, connecting applications with instances instantiated at multiple locations is like having multiple Egress routers towards the same destination (ANYCAST). For example, to reach an application B instantiated at B1, B2, B3, which corresponds to egress ER1, ER2, ER3 respectively, the Shortest Path Computation need to include both routing distance and the resources attached to ER1, ER2, ER3. i.e. the cost in the ECMP (Equal Cost Multiple Path) should include both the routing distances and the resource cost. [LES:] What I am saying is that you need to do load balancing at the Application Layer – not at Layer 3. IGPs can provide you with paths to the set of Application servers that share the same anycast address – but dynamically manipulating the IGP metrics (even this new metric you propose) – will give you oscillation – not application server load balancing. Suggested solution: Using TLV 128 and 130 to carry the “aggregated site cost” (associated t the Egress router) is suggested by Peter Psenak (through the offline discussion prior to the IETF 112, see the attached email thread) There is only one sentence in the Section 6, which is per Peter’s suggestion: “Aggregated Cost appended to the IP Reachability TLV: 128, 130, or 135.” Why do you say it is a “mess”? I felt your words are more like personal attack than giving a constructive suggestion. [LES:] Apologies if you were offended – I did put a smiley in to try give it a light touch – but I should know better than to be so flippant in this context. My point is that in what is indeed a very small section there are multiple errors: * The TLVs mentioned are not correct * The diagram with the proposed sub-TLV encoding incorrectly includes the prefix. The prefix is already present in the parent TLV – it should not be present in the sub-TLV. You have this correct in Section 5 for OSPF. But these points can be ignored because I believe using the IGPs isn’t the right solution and so we won’t need these new sub-TLVs anyway. I don’t know what comment from Peter you are referring to – but if he mentioned TLVs 128/130 I will take that up with him – he knows better. I do recall that in an earlier version of the draft you were proposing to advertise the new metric as part of a link advertisement (TLV 22) – and he was quite correct in directing you to use Prefix Reachability advertisements (like TLV 135). But please focus on looking at a non-IGP solution – that is what you need to do IMO. Les Linda From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>> Sent: Monday, January 10, 2022 9:48 AM To: Linda Dunbar mailto:linda.dun.
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Good luck keeping the IGP stable at scale once you allow any external compute node to inject metrics into it. And if you do I do not see why one should be allowed and the other not. At least that is not for LSR WG to judge that IMHO. Cheers, R. On Wed, Jan 12, 2022 at 1:25 PM Acee Lindem (acee) wrote: > Speaking as WG member: > > > > From a 10,000 foot view, flex algorithm is the right place to introduce > new metrics as it assures uniform treatment of these metrics within the IGP > domain (only routers understanding the metrics are included in the SPT). > > > > What is being debated here is the issue of whether 5G application load > should be used by IGPs for route computation. > > > > Thanks, > > Acee > > > > *From: *Lsr on behalf of Robert Raszuk < > rob...@raszuk.net> > *Date: *Wednesday, January 12, 2022 at 6:07 AM > *To: *Aijun Wang > *Cc: *"Les Ginsberg (ginsberg)" , > lsr , Linda Dunbar > *Subject: *Re: [Lsr] Seeking feedback to the revised > draft-dunbar-lsr-5g-edge-compute > > > > Hi Aijun & Linda, > > > > I think based on your below comment you are putting an equal sign between > flexible network transport topologies vs flexible application driven > transport topologies. > > > > To the best of my understanding the intention of flexalgo is the former > and never was intended to take on the latter. > > > > I would be personally very hesitant to load any user application data onto > IGPs for lots of scale and stability reasons. It seems much wiser to keep > application distribution as an overlay and never inject any state into > transport. As we all know encapsulation at the application layer > effectively and in line rate helps with such clean hierarchy. > > > > Kind regards, > > Robert > > > > On Wed, Jan 12, 2022 at 8:44 AM Aijun Wang > wrote: > > Hi, Les: > > > > IGP is now considering the dynamic metric(for example, the delay metric > within flexalgo), not only the static metic. > > The proposed “AggCost” is also one kind of dynamic metric. It can assist > the new clients to avoid the already heavy-burden application server. > > With the “Flow Affinity to an ANYCAST server” capabilities that mentioned > in > https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-03#section-13, > the oscillation phenomena can be mitigated for the existing client/server > flow. > > Or else, all the dynamic cost can’t be used within the IGP. > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > *From:* lsr-boun...@ietf.org *On Behalf Of *Les > Ginsberg (ginsberg) > *Sent:* Wednesday, January 12, 2022 1:14 PM > *To:* Linda Dunbar ; lsr@ietf.org > *Subject:* Re: [Lsr] Seeking feedback to the revised > draft-dunbar-lsr-5g-edge-compute > > > > Linda - > > > > *From:* Linda Dunbar > *Sent:* Tuesday, January 11, 2022 7:47 PM > *To:* Les Ginsberg (ginsberg) ; lsr@ietf.org > *Subject:* RE: Seeking feedback to the revised > draft-dunbar-lsr-5g-edge-compute > > > > Les, > > > > Starting with a clean slate: > > > > *Problem: * > > Most applications are instantiated at multiple locations to achieve > optimal performance. Traditional shortest path to reach one single > destination is making load balancers the bottleneck, or pushing the traffic > management responsibility to DNS. > > > > From Underlay IP network perspective, connecting applications with > instances instantiated at multiple locations is like having multiple Egress > routers towards the same destination (ANYCAST). > > For example, to reach an application B instantiated at B1, B2, B3, which > corresponds to egress ER1, ER2, ER3 respectively, the Shortest Path > Computation need to include both routing distance and the resources > attached to ER1, ER2, ER3. i.e. the cost in the ECMP (Equal Cost Multiple > Path) should include both the routing distances and the resource cost. > > > > *[LES:] What I am saying is that you need to do load balancing at the > Application Layer – not at Layer 3.* > > *IGPs can provide you with paths to the set of Application servers that > share the same anycast address – but dynamically manipulating the IGP > metrics (even this new metric you propose) – will give you oscillation – > not application server load balancing.* > > > > > > *Suggested solution:* > > Using TLV 128 and 130 to carry the “aggregated site cost” (associated t > the Egress router) is suggested by Peter Psenak (through the offline > discussion prior to the IETF 112, see the attached email thread) > > > > There is o
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Speaking as WG member: From a 10,000 foot view, flex algorithm is the right place to introduce new metrics as it assures uniform treatment of these metrics within the IGP domain (only routers understanding the metrics are included in the SPT). What is being debated here is the issue of whether 5G application load should be used by IGPs for route computation. Thanks, Acee From: Lsr on behalf of Robert Raszuk Date: Wednesday, January 12, 2022 at 6:07 AM To: Aijun Wang Cc: "Les Ginsberg (ginsberg)" , lsr , Linda Dunbar Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Hi Aijun & Linda, I think based on your below comment you are putting an equal sign between flexible network transport topologies vs flexible application driven transport topologies. To the best of my understanding the intention of flexalgo is the former and never was intended to take on the latter. I would be personally very hesitant to load any user application data onto IGPs for lots of scale and stability reasons. It seems much wiser to keep application distribution as an overlay and never inject any state into transport. As we all know encapsulation at the application layer effectively and in line rate helps with such clean hierarchy. Kind regards, Robert On Wed, Jan 12, 2022 at 8:44 AM Aijun Wang mailto:wangai...@tsinghua.org.cn>> wrote: Hi, Les: IGP is now considering the dynamic metric(for example, the delay metric within flexalgo), not only the static metic. The proposed “AggCost” is also one kind of dynamic metric. It can assist the new clients to avoid the already heavy-burden application server. With the “Flow Affinity to an ANYCAST server” capabilities that mentioned in https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-03#section-13, the oscillation phenomena can be mitigated for the existing client/server flow. Or else, all the dynamic cost can’t be used within the IGP. Best Regards Aijun Wang China Telecom From: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> mailto:lsr-boun...@ietf.org>> On Behalf Of Les Ginsberg (ginsberg) Sent: Wednesday, January 12, 2022 1:14 PM To: Linda Dunbar mailto:linda.dun...@futurewei.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Linda - From: Linda Dunbar mailto:linda.dun...@futurewei.com>> Sent: Tuesday, January 11, 2022 7:47 PM To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Les, Starting with a clean slate: Problem: Most applications are instantiated at multiple locations to achieve optimal performance. Traditional shortest path to reach one single destination is making load balancers the bottleneck, or pushing the traffic management responsibility to DNS. From Underlay IP network perspective, connecting applications with instances instantiated at multiple locations is like having multiple Egress routers towards the same destination (ANYCAST). For example, to reach an application B instantiated at B1, B2, B3, which corresponds to egress ER1, ER2, ER3 respectively, the Shortest Path Computation need to include both routing distance and the resources attached to ER1, ER2, ER3. i.e. the cost in the ECMP (Equal Cost Multiple Path) should include both the routing distances and the resource cost. [LES:] What I am saying is that you need to do load balancing at the Application Layer – not at Layer 3. IGPs can provide you with paths to the set of Application servers that share the same anycast address – but dynamically manipulating the IGP metrics (even this new metric you propose) – will give you oscillation – not application server load balancing. Suggested solution: Using TLV 128 and 130 to carry the “aggregated site cost” (associated t the Egress router) is suggested by Peter Psenak (through the offline discussion prior to the IETF 112, see the attached email thread) There is only one sentence in the Section 6, which is per Peter’s suggestion: “Aggregated Cost appended to the IP Reachability TLV: 128, 130, or 135.” Why do you say it is a “mess”? I felt your words are more like personal attack than giving a constructive suggestion. [LES:] Apologies if you were offended – I did put a smiley in to try give it a light touch – but I should know better than to be so flippant in this context. My point is that in what is indeed a very small section there are multiple errors: • The TLVs mentioned are not correct • The diagram with the proposed sub-TLV encoding incorrectly includes the prefix. The prefix is already present in the parent TLV – it should not be present in the sub-TLV. You have this correct in Section 5 for OSPF. But these points can be ignored because I believe using the IGPs isn’t the rig
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Hi, Les: IGP is now considering the dynamic metric(for example, the delay metric within flexalgo), not only the static metic. The proposed “AggCost” is also one kind of dynamic metric. It can assist the new clients to avoid the already heavy-burden application server. With the “Flow Affinity to an ANYCAST server” capabilities that mentioned in https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-03#section-13, the oscillation phenomena can be mitigated for the existing client/server flow. Or else, all the dynamic cost can’t be used within the IGP. Best Regards Aijun Wang China Telecom From: lsr-boun...@ietf.org On Behalf Of Les Ginsberg (ginsberg) Sent: Wednesday, January 12, 2022 1:14 PM To: Linda Dunbar ; lsr@ietf.org Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Linda - From: Linda Dunbar mailto:linda.dun...@futurewei.com> > Sent: Tuesday, January 11, 2022 7:47 PM To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com> >; lsr@ietf.org <mailto:lsr@ietf.org> Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Les, Starting with a clean slate: Problem: Most applications are instantiated at multiple locations to achieve optimal performance. Traditional shortest path to reach one single destination is making load balancers the bottleneck, or pushing the traffic management responsibility to DNS. >From Underlay IP network perspective, connecting applications with instances >instantiated at multiple locations is like having multiple Egress routers >towards the same destination (ANYCAST). For example, to reach an application B instantiated at B1, B2, B3, which corresponds to egress ER1, ER2, ER3 respectively, the Shortest Path Computation need to include both routing distance and the resources attached to ER1, ER2, ER3. i.e. the cost in the ECMP (Equal Cost Multiple Path) should include both the routing distances and the resource cost. [LES:] What I am saying is that you need to do load balancing at the Application Layer – not at Layer 3. IGPs can provide you with paths to the set of Application servers that share the same anycast address – but dynamically manipulating the IGP metrics (even this new metric you propose) – will give you oscillation – not application server load balancing. Suggested solution: Using TLV 128 and 130 to carry the “aggregated site cost” (associated t the Egress router) is suggested by Peter Psenak (through the offline discussion prior to the IETF 112, see the attached email thread) There is only one sentence in the Section 6, which is per Peter’s suggestion: “Aggregated Cost appended to the IP Reachability TLV: 128, 130, or 135.” Why do you say it is a “mess”? I felt your words are more like personal attack than giving a constructive suggestion. [LES:] Apologies if you were offended – I did put a smiley in to try give it a light touch – but I should know better than to be so flippant in this context. My point is that in what is indeed a very small section there are multiple errors: · The TLVs mentioned are not correct · The diagram with the proposed sub-TLV encoding incorrectly includes the prefix. The prefix is already present in the parent TLV – it should not be present in the sub-TLV. You have this correct in Section 5 for OSPF. But these points can be ignored because I believe using the IGPs isn’t the right solution and so we won’t need these new sub-TLVs anyway. I don’t know what comment from Peter you are referring to – but if he mentioned TLVs 128/130 I will take that up with him – he knows better. I do recall that in an earlier version of the draft you were proposing to advertise the new metric as part of a link advertisement (TLV 22) – and he was quite correct in directing you to use Prefix Reachability advertisements (like TLV 135). But please focus on looking at a non-IGP solution – that is what you need to do IMO. Les Linda From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com> > Sent: Monday, January 10, 2022 9:48 AM To: Linda Dunbar mailto:linda.dun...@futurewei.com> >; lsr@ietf.org <mailto:lsr@ietf.org> Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Linda – I believe the most valuable feedback you received during your presentation at IETF 112 is that using IGPs likely will not meet the deployment requirements. In particular, persistence of a given client session with a given application server is likely a requirement which will not be achieved using an IGP based solution. Also, the modification of IGP metrics will likely introduce unwanted oscillation in traffic flows. I suggest you start with a clean slate – focus on defining what all the requirements are without regard to what mechanism/protocol might be use
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Linda - From: Linda Dunbar Sent: Tuesday, January 11, 2022 7:47 PM To: Les Ginsberg (ginsberg) ; lsr@ietf.org Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Les, Starting with a clean slate: Problem: Most applications are instantiated at multiple locations to achieve optimal performance. Traditional shortest path to reach one single destination is making load balancers the bottleneck, or pushing the traffic management responsibility to DNS. From Underlay IP network perspective, connecting applications with instances instantiated at multiple locations is like having multiple Egress routers towards the same destination (ANYCAST). For example, to reach an application B instantiated at B1, B2, B3, which corresponds to egress ER1, ER2, ER3 respectively, the Shortest Path Computation need to include both routing distance and the resources attached to ER1, ER2, ER3. i.e. the cost in the ECMP (Equal Cost Multiple Path) should include both the routing distances and the resource cost. [LES:] What I am saying is that you need to do load balancing at the Application Layer – not at Layer 3. IGPs can provide you with paths to the set of Application servers that share the same anycast address – but dynamically manipulating the IGP metrics (even this new metric you propose) – will give you oscillation – not application server load balancing. Suggested solution: Using TLV 128 and 130 to carry the “aggregated site cost” (associated t the Egress router) is suggested by Peter Psenak (through the offline discussion prior to the IETF 112, see the attached email thread) There is only one sentence in the Section 6, which is per Peter’s suggestion: “Aggregated Cost appended to the IP Reachability TLV: 128, 130, or 135.” Why do you say it is a “mess”? I felt your words are more like personal attack than giving a constructive suggestion. [LES:] Apologies if you were offended – I did put a smiley in to try give it a light touch – but I should know better than to be so flippant in this context. My point is that in what is indeed a very small section there are multiple errors: * The TLVs mentioned are not correct * The diagram with the proposed sub-TLV encoding incorrectly includes the prefix. The prefix is already present in the parent TLV – it should not be present in the sub-TLV. You have this correct in Section 5 for OSPF. But these points can be ignored because I believe using the IGPs isn’t the right solution and so we won’t need these new sub-TLVs anyway. I don’t know what comment from Peter you are referring to – but if he mentioned TLVs 128/130 I will take that up with him – he knows better. I do recall that in an earlier version of the draft you were proposing to advertise the new metric as part of a link advertisement (TLV 22) – and he was quite correct in directing you to use Prefix Reachability advertisements (like TLV 135). But please focus on looking at a non-IGP solution – that is what you need to do IMO. Les Linda From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>> Sent: Monday, January 10, 2022 9:48 AM To: Linda Dunbar mailto:linda.dun...@futurewei.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Linda – I believe the most valuable feedback you received during your presentation at IETF 112 is that using IGPs likely will not meet the deployment requirements. In particular, persistence of a given client session with a given application server is likely a requirement which will not be achieved using an IGP based solution. Also, the modification of IGP metrics will likely introduce unwanted oscillation in traffic flows. I suggest you start with a clean slate – focus on defining what all the requirements are without regard to what mechanism/protocol might be used – and then think about defining a solution which meets these requirements. I think you will end up NOT using routing protocols at all. On a more mundane note, the section describing the new IS-IS advertisement (https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-03#section-6<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-dunbar-lsr-5g-edge-compute-03%23section-6=04%7C01%7Clinda.dunbar%40futurewei.com%7Cd99499e3006a4a3d4f5808d9d450a22a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637774265066903950%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=ZJY0ugnVuhUmc6o%2Bje2FDhnAcSo2tvhxYn4c3YFxcFM%3D=0> ) is – to put it bluntly – a mess! TLVs 128 and 130 are legacy TLVs which don’t support sub-TLVs – they should not be mentioned at all. And the encoding diagram shows a “prefix” being advertised in the new sub-TLV when it should not. The prefix has already been advertised in the parent TLV. Les From: Lsr mailto:lsr-boun
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Les, Starting with a clean slate: Problem: Most applications are instantiated at multiple locations to achieve optimal performance. Traditional shortest path to reach one single destination is making load balancers the bottleneck, or pushing the traffic management responsibility to DNS. From Underlay IP network perspective, connecting applications with instances instantiated at multiple locations is like having multiple Egress routers towards the same destination (ANYCAST). For example, to reach an application B instantiated at B1, B2, B3, which corresponds to egress ER1, ER2, ER3 respectively, the Shortest Path Computation need to include both routing distance and the resources attached to ER1, ER2, ER3. i.e. the cost in the ECMP (Equal Cost Multiple Path) should include both the routing distances and the resource cost. Suggested solution: Using TLV 128 and 130 to carry the “aggregated site cost” (associated t the Egress router) is suggested by Peter Psenak (through the offline discussion prior to the IETF 112, see the attached email thread) There is only one sentence in the Section 6, which is per Peter’s suggestion: “Aggregated Cost appended to the IP Reachability TLV: 128, 130, or 135.” Why do you say it is a “mess”? I felt your words are more like personal attack than giving a constructive suggestion. Linda From: Les Ginsberg (ginsberg) Sent: Monday, January 10, 2022 9:48 AM To: Linda Dunbar ; lsr@ietf.org Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Linda – I believe the most valuable feedback you received during your presentation at IETF 112 is that using IGPs likely will not meet the deployment requirements. In particular, persistence of a given client session with a given application server is likely a requirement which will not be achieved using an IGP based solution. Also, the modification of IGP metrics will likely introduce unwanted oscillation in traffic flows. I suggest you start with a clean slate – focus on defining what all the requirements are without regard to what mechanism/protocol might be used – and then think about defining a solution which meets these requirements. I think you will end up NOT using routing protocols at all. On a more mundane note, the section describing the new IS-IS advertisement (https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-03#section-6<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-dunbar-lsr-5g-edge-compute-03%23section-6=04%7C01%7Clinda.dunbar%40futurewei.com%7Cd99499e3006a4a3d4f5808d9d450a22a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637774265066903950%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=ZJY0ugnVuhUmc6o%2Bje2FDhnAcSo2tvhxYn4c3YFxcFM%3D=0> ) is – to put it bluntly – a mess! TLVs 128 and 130 are legacy TLVs which don’t support sub-TLVs – they should not be mentioned at all. And the encoding diagram shows a “prefix” being advertised in the new sub-TLV when it should not. The prefix has already been advertised in the parent TLV. Les From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Linda Dunbar Sent: Friday, January 7, 2022 11:29 AM To: lsr@ietf.org<mailto:lsr@ietf.org> Subject: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute LSR experts, We have revised the draft-dunbar-lsr-5g-edge-compute to address the comments and feedback from IETF 112. 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=04%7C01%7Clinda.dunbar%40futurewei.com%7Cd99499e3006a4a3d4f5808d9d450a22a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637774265067060188%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=GXrGqw4CNac27y1cIY9dC68j3%2FKx1x5kCzPtoPMCUUs%3D=0> In a nutshell, the proposed solution * advertises the “Site-Cost” via IP prefix reachability TLV associated with the (anycast) prefix The Site-Cost is the aggregated cost associated with an Edge Compute (EC) server (i.e., ANYCAST prefix), computed based on the IP layer related metrics for the prefix, such as Load Measurement, the Capacity Index, the Preference Index, and other constraints by a consistent algorithm across all egress routers to which the EC servers are attached. * Uses a Flag in the Flexible Algorithm TLV to indicate that “site-cost” needs to be included for the constrained SPF to reach the Prefix Any feedbacks? Or suggestions? Thank you very much Linda --- Begin Message --- Linda, On 09/11/2021 18:09, Linda Dunbar wrote: > Peter, > You suggested creating a new sub-TLV for E-Intra-Area-Prefix-LSA, > E-Inter-Area-Prefix-LSA, E-AS-External-LSA, and E-Type-7-LSA [RFC8362]. > But if we use the original Intra/Inter-area
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Hi Aijun, > Just because some mechanism wants to use toplogy information does NOT imply > that it should be part of the routing protocol. > > In this case, load balancing should be an independent mechanism. If it wants > to peek into the LSDB, that would be perfectly acceptable, IMHO. > [WAJ] Current LSDB doesn’t include the aggregated cost that can be used to > select the optimal application server. So please feel free to add whatever costs you want to circulate to whatever other load balancing protocol you come up with. > If they are separated, the router should do the SPF calculation twice. Using > the constrained SPF/flexalgo to achieve such optimal goal is certainly better > than calculate twice. I don’t understand or believe this. We have been running multiple SPFs since the early days of TE. This is Not A Big Deal. Tony ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Hi, Tony: From: lsr-boun...@ietf.org On Behalf Of Tony Li Sent: Tuesday, January 11, 2022 4:20 AM To: Aijun Wang Cc: Les Ginsberg (ginsberg) ; lsr ; Linda Dunbar Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute On Jan 10, 2022, at 9:05 AM, Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote: [WAJ] Selecting the most appropriate/optimized application server should base on the topology information which is routing protocol related. Just because some mechanism wants to use toplogy information does NOT imply that it should be part of the routing protocol. In this case, load balancing should be an independent mechanism. If it wants to peek into the LSDB, that would be perfectly acceptable, IMHO. [WAJ] Current LSDB doesn't include the aggregated cost that can be used to select the optimal application server. If they are separated, the router should do the SPF calculation twice. Using the constrained SPF/flexalgo to achieve such optimal goal is certainly better than calculate twice. Tony ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Hi, Les: From: Les Ginsberg (ginsberg) Sent: Tuesday, January 11, 2022 4:55 AM To: Aijun Wang ; Les Ginsberg (ginsberg) Cc: lsr@ietf.org; Linda Dunbar Subject: RE: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Aijun – Top posting here. I think what is desired is load balancing at the application layer – coupled with persistence of a given flow (AKA client-server connection). You aren’t going to achieve that by dynamically adjusting IGP costs. And you are likely to get oscillation – which is undesirable. [WAJ] The IGP costs that related to the application layer is at the stub end of the link. It is not the transit link that other pairs of services will also use. \ Then adjust such costs on demand doesn’t influence any transit traffic, the oscillation that you are worrying will not happen. As regards the relationship between draft-dunbar-lsr-5g-edge-compute and draft-wang-lsr-stub-link-attributes, I noted that in my reading but chose not to discuss it as my concerns with each draft are more fundamental and I did not want to distract. But since you mention this, draft-dunbar-lsr-5g-edge-compute is proposing to advertise new prefix related information. draft-wang-lsr-stub-link-attributes is proposing to advertise new link related information. This difference matters to me – though it seems it does not to you. One reason why we will never agree about this. [WAJ] Actually, I prefer to advertise such information with the link, not the prefixes. The application prefixes should also be the attributes of the link(specially, stub link). This is the consistent way. As regards the IS-IS encoding, please look at the equivalent proposed OSPF encoding in the previous section and ask yourself why they are different. [WAJ] I think you can refer to https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-03#section-7. In this section, we have illustrate that “It would be better if the aggregated cost could be advertised (in) the same way, regardless of OSPFv2, OSPFv3, or ISIS.“ Les From: Lsr mailto:lsr-boun...@ietf.org> > On Behalf Of Aijun Wang Sent: Monday, January 10, 2022 9:05 AM To: Les Ginsberg (ginsberg) mailto:ginsberg=40cisco@dmarc.ietf.org> > Cc: lsr@ietf.org <mailto:lsr@ietf.org> ; Linda Dunbar mailto:linda.dun...@futurewei.com> > Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Hi, Les: Aijun Wang China Telecom On Jan 10, 2022, at 23:48, Les Ginsberg (ginsberg) mailto:ginsberg=40cisco@dmarc.ietf.org> > wrote: Linda – I believe the most valuable feedback you received during your presentation at IETF 112 is that using IGPs likely will not meet the deployment requirements. In particular, persistence of a given client session with a given application server is likely a requirement which will not be achieved using an IGP based solution. [WAJ] The main aim of draft is to how assist the router to select the most appropriate application servers, with regards to the metrics that is not limited to the link cost. Also, the modification of IGP metrics will likely introduce unwanted oscillation in traffic flows. [WAJ] These metrics are associated with the links that doesn’t participate in the IGP, that is, they are the characteristics of the “Stub-Link”, then only the application that utilize such information will be influenced, or optimized. I suggest you start with a clean slate – focus on defining what all the requirements are without regard to what mechanism/protocol might be used – and then think about defining a solution which meets these requirements. I think you will end up NOT using routing protocols at all [WAJ] Selecting the most appropriate/optimized application server should base on the topology information which is routing protocol related. On a more mundane note, the section describing the new IS-IS advertisement (https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-03#section-6 ) is – to put it bluntly – a mess! TLVs 128 and 130 are legacy TLVs which don’t support sub-TLVs – they should not be mentioned at all. And the encoding diagram shows a “prefix” being advertised in the new sub-TLV when it should not. The prefix has already been advertised in the parent TLV. [WAJ] Actually, the most appropriate place to convey such information is via the Stub-Link TLV/Sub-TLV that defined in https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-02 Les From: Lsr mailto:lsr-boun...@ietf.org> > On Behalf Of Linda Dunbar Sent: Friday, January 7, 2022 11:29 AM To: lsr@ietf.org <mailto:lsr@ietf.org> Subject: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute LSR experts, We have revised the draft-dunbar-lsr-5g-edge-compute to address the comments and feedback from IETF 112
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Aijun – Top posting here. I think what is desired is load balancing at the application layer – coupled with persistence of a given flow (AKA client-server connection). You aren’t going to achieve that by dynamically adjusting IGP costs. And you are likely to get oscillation – which is undesirable. As regards the relationship between draft-dunbar-lsr-5g-edge-compute and draft-wang-lsr-stub-link-attributes, I noted that in my reading but chose not to discuss it as my concerns with each draft are more fundamental and I did not want to distract. But since you mention this, draft-dunbar-lsr-5g-edge-compute is proposing to advertise new prefix related information. draft-wang-lsr-stub-link-attributes is proposing to advertise new link related information. This difference matters to me – though it seems it does not to you. One reason why we will never agree about this. As regards the IS-IS encoding, please look at the equivalent proposed OSPF encoding in the previous section and ask yourself why they are different. Les From: Lsr On Behalf Of Aijun Wang Sent: Monday, January 10, 2022 9:05 AM To: Les Ginsberg (ginsberg) Cc: lsr@ietf.org; Linda Dunbar Subject: Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute Hi, Les: Aijun Wang China Telecom On Jan 10, 2022, at 23:48, Les Ginsberg (ginsberg) mailto:ginsberg=40cisco@dmarc.ietf.org>> wrote: Linda – I believe the most valuable feedback you received during your presentation at IETF 112 is that using IGPs likely will not meet the deployment requirements. In particular, persistence of a given client session with a given application server is likely a requirement which will not be achieved using an IGP based solution. [WAJ] The main aim of draft is to how assist the router to select the most appropriate application servers, with regards to the metrics that is not limited to the link cost. Also, the modification of IGP metrics will likely introduce unwanted oscillation in traffic flows. [WAJ] These metrics are associated with the links that doesn’t participate in the IGP, that is, they are the characteristics of the “Stub-Link”, then only the application that utilize such information will be influenced, or optimized. I suggest you start with a clean slate – focus on defining what all the requirements are without regard to what mechanism/protocol might be used – and then think about defining a solution which meets these requirements. I think you will end up NOT using routing protocols at all [WAJ] Selecting the most appropriate/optimized application server should base on the topology information which is routing protocol related. On a more mundane note, the section describing the new IS-IS advertisement (https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-03#section-6 ) is – to put it bluntly – a mess! TLVs 128 and 130 are legacy TLVs which don’t support sub-TLVs – they should not be mentioned at all. And the encoding diagram shows a “prefix” being advertised in the new sub-TLV when it should not. The prefix has already been advertised in the parent TLV. [WAJ] Actually, the most appropriate place to convey such information is via the Stub-Link TLV/Sub-TLV that defined in https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-02 Les From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Linda Dunbar Sent: Friday, January 7, 2022 11:29 AM To: lsr@ietf.org<mailto:lsr@ietf.org> Subject: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute LSR experts, We have revised the draft-dunbar-lsr-5g-edge-compute to address the comments and feedback from IETF 112. https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute/ In a nutshell, the proposed solution * advertises the “Site-Cost” via IP prefix reachability TLV associated with the (anycast) prefix The Site-Cost is the aggregated cost associated with an Edge Compute (EC) server (i.e., ANYCAST prefix), computed based on the IP layer related metrics for the prefix, such as Load Measurement, the Capacity Index, the Preference Index, and other constraints by a consistent algorithm across all egress routers to which the EC servers are attached. * Uses a Flag in the Flexible Algorithm TLV to indicate that “site-cost” needs to be included for the constrained SPF to reach the Prefix Any feedbacks? Or suggestions? Thank you very much Linda ___ Lsr mailing list Lsr@ietf.org<mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
> On Jan 10, 2022, at 9:05 AM, Aijun Wang wrote: > > [WAJ] Selecting the most appropriate/optimized application server should base > on the topology information which is routing protocol related. Just because some mechanism wants to use toplogy information does NOT imply that it should be part of the routing protocol. In this case, load balancing should be an independent mechanism. If it wants to peek into the LSDB, that would be perfectly acceptable, IMHO. Tony ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Hi, Les: Aijun Wang China Telecom > On Jan 10, 2022, at 23:48, Les Ginsberg (ginsberg) > wrote: > > > Linda – > > I believe the most valuable feedback you received during your presentation at > IETF 112 is that using IGPs likely will not meet the deployment requirements. > In particular, persistence of a given client session with a given application > server is likely a requirement which will not be achieved using an IGP based > solution. [WAJ] The main aim of draft is to how assist the router to select the most appropriate application servers, with regards to the metrics that is not limited to the link cost. > Also, the modification of IGP metrics will likely introduce unwanted > oscillation in traffic flows. [WAJ] These metrics are associated with the links that doesn’t participate in the IGP, that is, they are the characteristics of the “Stub-Link”, then only the application that utilize such information will be influenced, or optimized. > > I suggest you start with a clean slate – focus on defining what all the > requirements are without regard to what mechanism/protocol might be used – > and then think about defining a solution which meets these requirements. > I think you will end up NOT using routing protocols at all [WAJ] Selecting the most appropriate/optimized application server should base on the topology information which is routing protocol related. > > On a more mundane note, the section describing the new IS-IS advertisement > (https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-03#section-6 > ) is – to put it bluntly – a mess! > TLVs 128 and 130 are legacy TLVs which don’t support sub-TLVs – they should > not be mentioned at all. > And the encoding diagram shows a “prefix” being advertised in the new sub-TLV > when it should not. The prefix has already been advertised in the parent TLV. [WAJ] Actually, the most appropriate place to convey such information is via the Stub-Link TLV/Sub-TLV that defined in https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-02 > >Les > > > From: Lsr On Behalf Of Linda Dunbar > Sent: Friday, January 7, 2022 11:29 AM > To: lsr@ietf.org > Subject: [Lsr] Seeking feedback to the revised > draft-dunbar-lsr-5g-edge-compute > > LSR experts, > > We have revised the draft-dunbar-lsr-5g-edge-compute to address the comments > and feedback from IETF 112. > https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute/ > > In a nutshell, the proposed solution > advertises the “Site-Cost” via IP prefix reachability TLV associated with the > (anycast) prefix > The Site-Cost is the aggregated cost associated with an Edge Compute (EC) > server (i.e., ANYCAST prefix), computed based on the IP layer related metrics > for the prefix, such as Load Measurement, the Capacity Index, the Preference > Index, and other constraints by a consistent algorithm across all egress > routers to which the EC servers are attached. > > Uses a Flag in the Flexible Algorithm TLV to indicate that “site-cost” needs > to be included for the constrained SPF to reach the Prefix > > > Any feedbacks? Or suggestions? > > Thank you very much > Linda > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Linda – I believe the most valuable feedback you received during your presentation at IETF 112 is that using IGPs likely will not meet the deployment requirements. In particular, persistence of a given client session with a given application server is likely a requirement which will not be achieved using an IGP based solution. Also, the modification of IGP metrics will likely introduce unwanted oscillation in traffic flows. I suggest you start with a clean slate – focus on defining what all the requirements are without regard to what mechanism/protocol might be used – and then think about defining a solution which meets these requirements. I think you will end up NOT using routing protocols at all. On a more mundane note, the section describing the new IS-IS advertisement (https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-03#section-6 ) is – to put it bluntly – a mess! TLVs 128 and 130 are legacy TLVs which don’t support sub-TLVs – they should not be mentioned at all. And the encoding diagram shows a “prefix” being advertised in the new sub-TLV when it should not. The prefix has already been advertised in the parent TLV. Les From: Lsr On Behalf Of Linda Dunbar Sent: Friday, January 7, 2022 11:29 AM To: lsr@ietf.org Subject: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute LSR experts, We have revised the draft-dunbar-lsr-5g-edge-compute to address the comments and feedback from IETF 112. https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute/ In a nutshell, the proposed solution * advertises the “Site-Cost” via IP prefix reachability TLV associated with the (anycast) prefix The Site-Cost is the aggregated cost associated with an Edge Compute (EC) server (i.e., ANYCAST prefix), computed based on the IP layer related metrics for the prefix, such as Load Measurement, the Capacity Index, the Preference Index, and other constraints by a consistent algorithm across all egress routers to which the EC servers are attached. * Uses a Flag in the Flexible Algorithm TLV to indicate that “site-cost” needs to be included for the constrained SPF to reach the Prefix Any feedbacks? Or suggestions? Thank you very much Linda ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
LSR experts, We have revised the draft-dunbar-lsr-5g-edge-compute to address the comments and feedback from IETF 112. https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute/ In a nutshell, the proposed solution * advertises the "Site-Cost" via IP prefix reachability TLV associated with the (anycast) prefix The Site-Cost is the aggregated cost associated with an Edge Compute (EC) server (i.e., ANYCAST prefix), computed based on the IP layer related metrics for the prefix, such as Load Measurement, the Capacity Index, the Preference Index, and other constraints by a consistent algorithm across all egress routers to which the EC servers are attached. * Uses a Flag in the Flexible Algorithm TLV to indicate that "site-cost" needs to be included for the constrained SPF to reach the Prefix Any feedbacks? Or suggestions? Thank you very much Linda ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
