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) <a...@cisco.com>
Sent: Wednesday, January 19, 2022 7:18 AM
To: Linda Dunbar <linda.dun...@futurewei.com>; Robert Raszuk 
<rob...@raszuk.net>; Aijun Wang <wangai...@tsinghua.org.cn>
Cc: John E Drake <jdr...@juniper.net>; Les Ginsberg (ginsberg) 
<ginsb...@cisco.com>; Gyan Mishra <hayabusa...@gmail.com>; lsr <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 
<linda.dun...@futurewei.com<mailto:linda.dun...@futurewei.com>>
Date: Tuesday, January 18, 2022 at 10:52 PM
To: Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>, Aijun Wang 
<wangai...@tsinghua.org.cn<mailto:wangai...@tsinghua.org.cn>>
Cc: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, John E Drake 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>, "Les Ginsberg (ginsberg)" 
<ginsb...@cisco.com<mailto:ginsb...@cisco.com>>, Gyan Mishra 
<hayabusa...@gmail.com<mailto:hayabusa...@gmail.com>>, lsr 
<lsr@ietf.org<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 <rob...@raszuk.net<mailto:rob...@raszuk.net>>
Sent: Monday, January 17, 2022 5:29 AM
To: Aijun Wang <wangai...@tsinghua.org.cn<mailto:wangai...@tsinghua.org.cn>>
Cc: Acee Lindem (acee) 
<acee=40cisco....@dmarc.ietf.org<mailto:acee=40cisco....@dmarc.ietf.org>>; 
Linda Dunbar <linda.dun...@futurewei.com<mailto:linda.dun...@futurewei.com>>; 
John E Drake 
<jdrake=40juniper....@dmarc.ietf.org<mailto:jdrake=40juniper....@dmarc.ietf.org>>;
 Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>; Gyan 
Mishra <hayabusa...@gmail.com<mailto:hayabusa...@gmail.com>>; lsr 
<lsr@ietf.org<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

Reply via email to