Re: [Lsr] Comments on draft-dunbar-lsr-5g-edge-compute-ospf-ext-03

[Linda Dunbar <[e-mail]>]

Acee,

Thank you very much for your comments.
Answers are inserted below.

Linda
From: Acee Lindem (acee) <[e-mail]>
Sent: Monday, March 8, 2021 2:12 PM
To: [e-mail]
Cc: [e-mail]
Subject: Comments on draft-dunbar-lsr-5g-edge-compute-ospf-ext-03

Speaking as WG member:

Hi Linda and Co-authors,

My first major comment is the confusion with the usage of multiple anycast addresses for the same application. Why are you requiring multiple anycast address? It would seem the load balancing over multiple servers can be done at the data center layer. I guess a UE would use the same anycast address for an application based on the initial DNS query? It is very confusing.

[Linda] Yeh, agree with you. It is kind of confusing.  That was one of the proposed solutions  in  3GPP’s TR23.748.
With OSPF periodically advertising the reachability to the ANYCAST servers, all routers should automatically switch to an alternative location for the ANYCAST server.
 I will remove the Section 6 in the next revision.

My second major comment is that in section 4, you point out that an aggregated metric would solve the problem. However, the purported downside is that all the Application Egress Routers (A-ERs) would need to use the same algorithm to aggregate the various capacity measurements into a single metric. It would seem to be an even larger obstacle for all the OSPF routers in the area to support these new metrics and consistent routing based on those metrics.

[Linda] Agree with you. The solution is only useful for a small controlled network, for example,  the Application Function Controller could send the “aggregated cost” to the egress routers periodically.
Even though the solution description described in the Section 4 has very limited usage, I feel it is important to include it in the draft.
I change the text to the following

“If all egress routers that have direct connection to the App Servers can get periodic update of the aggregated cost to the App Servers or can be configured with a consistent algorithm to compute an aggregated cost that take into consideration the Load Measurement, Capacity value and Preference value, this aggregated cost can be considered as the Metric of the link to the App Server.
In this scenario, there is no protocol extension needed.”

Also, some minor comments:


  1.  Why do you talk about ACLs to determine the anycast addresses? Presumably, you wouldn’t even have these metrics available for other addresses.
[Linda]  There could be large number of addresses attached to each Egress router. The egress routers only need to measure the “Running Environment” for the addresses filtered by the ACLs.


  1.  Section 5 still references the misguided draft-wang-lsr-passive-interface-attribute draft. I believe you meant to remove this.
[Linda] AiJun has answered this question.

There are other nits as well but it doesn’t make sense to spend time on them at this stage.

Thanks,
Acee