Re: [Lsr] IP layer metrics collected by Edge routers - draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

[Joel M. Halpern]

If you want to experiment with unusual metrics, and minimize the degree 
to which you need consistency, maybe you should look at running a 
different routing protocol in this limited domain?  Rather than trying 
to make IS-IS and OSPF do something they are not designed for?  (While 
there are probably other alternatives, Babel comes to mind as a routing 
protocol designed with experimentaiton with metrics in mind.)

Yours,
Joel
On 7/14/2021 12:20 PM, Linda Dunbar wrote:
Acee,

The “limited domain” per RFC8799  is a special purposed network that 
have boundary, e.g. DetNet. For 5G EC, a Limited Domain network could be 
built specifically for Unmanned Aerial Vehicles (UAV), as specified by 
3GPP 23.748.  This UAV Limited Domain network has routers and links that 
connect the moving UAVs with the UAV control servers, the analytics 
functions, and data storages; has boundary and  may not have access to 
public internet.

Among those routers in the UAV Limited Domain, the routing distance 
alone is no longer enough in computing the optimal Path. Therefore, IGP 
is needed to distribute not only link bandwidth, but also the IP layer 
Metrics specified by draft-dunbar-lsr-5g-edge-compute-ext, specifically:

  * Capacity Index:

Is used to differentiate the running environment of the attached 
application server (analytics or data storages) that are identified by 
their IP addresses.  At some sites, the IP address exposed to the 
network is the App Layer Load balancer that have  many instances 
attached.  At other sites,  the IP address exposed is the server 
instance only.

“Capacity Index”, which is a numeric number configured by the Domain 
Controller on all A-ERs in the domain consistently , is used to 
represent the capacity of the application server attached to an A-ER.

  * Site preference index: 

Is used to describe some sites are more preferred than others for some 
flows that are identified by the IP header fields. “Site Preference 
Index”, which is a numeric number configured by the Domain Controller.

  * IP-Layer Metric for gauging the Load for the attached Prefix (i.e.,
    App Server):

The Load Measurement to an attached IP prefix (App Server) is a weighted 
combination of the number of packets/bytes to the IP prefix and the 
number of packets/bytes from the IP prefix which are collected by the 
A-ER that has the App Server directly attached.

An A-ER only collects those measurement for the prefixes instructed by 
the Domain Controller .

The work proposed is for the LSR Chartered Work Item “4) Extensions for 
source-destination routing”.

Is this description clear enough to move forward in the LSR WG?

Best regards, Linda Dunbar

*From:* Acee Lindem (acee) <a...@cisco.com>
*Sent:* Tuesday, July 13, 2021 2:46 PM
*To:* Linda Dunbar <linda.dun...@futurewei.com>; Yingzhen Qu 
<yingzhen.i...@gmail.com>; lsr@ietf.org
*Cc:* lsr-cha...@ietf.org
*Subject:* Re: IP layer metrics collected by Edge routers - 
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot 
request)

We seem to be in a circular discussion – we’re not standardizing 
loosely-defined metrics that only work in limited domains for OSPF and 
IS-IS. It is not a question of where.

Acee

*From: *Linda Dunbar <linda.dun...@futurewei.com 
<mailto:linda.dun...@futurewei.com>>
*Date: *Tuesday, July 13, 2021 at 3:42 PM
*To: *Acee Lindem <a...@cisco.com <mailto:a...@cisco.com>>, Yingzhen Qu 
<yingzhen.i...@gmail.com <mailto:yingzhen.i...@gmail.com>>, 
"lsr@ietf.org <mailto:lsr@ietf.org>" <lsr@ietf.org <mailto:lsr@ietf.org>>
*Cc: *"lsr-cha...@ietf.org <mailto:lsr-cha...@ietf.org>" 
<lsr-cha...@ietf.org <mailto:lsr-cha...@ietf.org>>
*Subject: *RE: IP layer metrics collected by Edge routers - 
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot 
request)

Acee,

Limited domain also needs IS-IS and OSPF  routing protocol (among 
routers in the limited domain). If not in LSR, where is the right place?

Linda

*From:* Acee Lindem (acee) <a...@cisco.com <mailto:a...@cisco.com>>
*Sent:* Tuesday, July 13, 2021 2:24 PM
*To:* Linda Dunbar <linda.dun...@futurewei.com 
<mailto:linda.dun...@futurewei.com>>; Yingzhen Qu 
<yingzhen.i...@gmail.com <mailto:yingzhen.i...@gmail.com>>; lsr@ietf.org 
<mailto:lsr@ietf.org>
*Cc:* lsr-cha...@ietf.org <mailto:lsr-cha...@ietf.org>
*Subject:* Re: IP layer metrics collected by Edge routers - 
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot 
request)

Linda – we’re not doing routing for limited domains in LSR. It doesn’t 
make any sense to go any further until you fix the draft or abandon it.

Thanks,

Acee

*From: *Linda Dunbar <linda.dun...@futurewei.com 
<mailto:linda.dun...@futurewei.com>>
*Date: *Tuesday, July 13, 2021 at 1:23 PM
*To: *Acee Lindem <a...@cisco.com <mailto:a...@cisco.com>>, Yingzhen Qu 
<yingzhen.i...@gmail.com <mailto:yingzhen.i...@gmail.com>>, 
"lsr@ietf.org <mailto:lsr@ietf.org>" <lsr@ietf.org <mailto:lsr@ietf.org>>
*Cc: *"lsr-cha...@ietf.org <mailto:lsr-cha...@ietf.org>" 
<lsr-cha...@ietf.org <mailto:lsr-cha...@ietf.org>>
*Subject: *RE: IP layer metrics collected by Edge routers - 
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot 
request)

Acee,

The scope of the draft is for IGP in the  Limited Domains per RFC8799, 
i.e. the small number of routers in the 5G LDN domain. Not meant for 
public Internet.

Answers to your questions are inserted below:

Linda

*From:* Acee Lindem (acee) <a...@cisco.com <mailto:a...@cisco.com>>
*Sent:* Monday, July 12, 2021 7:06 PM
*To:* Linda Dunbar <linda.dun...@futurewei.com 
<mailto:linda.dun...@futurewei.com>>; Yingzhen Qu 
<yingzhen.i...@gmail.com <mailto:yingzhen.i...@gmail.com>>; lsr@ietf.org 
<mailto:lsr@ietf.org>
*Cc:* lsr-cha...@ietf.org <mailto:lsr-cha...@ietf.org>
*Subject:* Re: IP layer metrics collected by Edge routers - 
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot 
request)

Hi Linda,

*From: *Linda Dunbar <linda.dun...@futurewei.com 
<mailto:linda.dun...@futurewei.com>>
*Date: *Monday, July 12, 2021 at 5:41 PM
*To: *Acee Lindem <a...@cisco.com <mailto:a...@cisco.com>>, Yingzhen Qu 
<yingzhen.i...@gmail.com <mailto:yingzhen.i...@gmail.com>>, 
"lsr@ietf.org <mailto:lsr@ietf.org>" <lsr@ietf.org <mailto:lsr@ietf.org>>
*Cc: *"lsr-cha...@ietf.org <mailto:lsr-cha...@ietf.org>" 
<lsr-cha...@ietf.org <mailto:lsr-cha...@ietf.org>>
*Subject: *IP layer metrics collected by Edge routers - 
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot 
request)

Acee,

The draft-dunbar-lsr-5g-edge-compute-ospf-ext has two parts:

-Aggregated Cost Advertisement

-IP Layer App-Metrics Advertisements by OSPF

“Aggregated Cost” is only applicable to scenario where all the A-ER can 
have a consistent algorithm to compute the Aggregated cost.

When it is not possible for all the egress edge routers to have a 
consistent algorithm to compute the aggregated cost or some routers need 
all the detailed IP Layer metrics for the App Servers for other 
purposes, the raw IP layer metrics collected A-ER will be distributed. 
Only the nodes that are capable of utilizing the metrics will process 
the sub-TLV.

So, why would these “capable” nodes have a consistent algorithm for 
using this complex set of metrics but the A-ERs would not have a 
consistent algorithm for aggregating the cost?

[Linda] Example of the nodes that need the metrics: analytic function 
(residing on one of the nodes in the LDN);  a small number of UPF 
functions that need the metrics.

Since only a subset of routers within an IGP domain need to know those 
detailed metrics, the draft used your suggested  OSPFv2 Extended Prefix 
Opaque LSA for IPv4 and OSPFv3 Extended LSA with Intra-Area-Prefix TLV 
to carry the detailed sub-TLVs.  For routers that don’t care about those 
metrics, they can ignore them very easily.

This just doesn’t work. All routers in an IGP domain must use the same 
algorithm. You can’t just draw a picture with an LDN directly connected 
to a couple A-ERs say that the LDNs can use your metrics to route 
application specific traffic. The problem could possibly be solved with 
flex algorithm but it would require a lot more specification. I guess 
with your simple topology different LDNs could use the metrics 
differently as well? This would explain why you are not concerned with 
“consistency”…  \

[Linda] The 5G LDN domain  is a limited domain per RFC 8799, and forms 
its own IGP domain. The “consistency is only for the limited nodes that 
are configured to utilize the IP layer metrics”. The IP Layer metrics is 
for nodes in this limited domain to supplement the forwarding path 
computation.

It worth noting that not all hosts (prefix) attached to an A-ER are 
ANYCAST servers that need network optimization. An A-ER only needs to 
advertise the App-Metrics for the ANYCAST addresses that match with the 
configured ACLs.

Note that routes are based on IP prefixes and not applications while the 
draft uses these two interchangeably.

[Linda] the Applications that need special consideration are identified 
by its IP address.

Thanks,

Acee

Any other concerns?

Thank you

Linda Dunbar

*From:* Acee Lindem (acee) <a...@cisco.com <mailto:a...@cisco.com>>
*Sent:* Monday, July 12, 2021 4:04 PM
*To:* Linda Dunbar <linda.dun...@futurewei.com 
<mailto:linda.dun...@futurewei.com>>; Yingzhen Qu 
<yingzhen.i...@gmail.com <mailto:yingzhen.i...@gmail.com>>; lsr@ietf.org 
<mailto:lsr@ietf.org>
*Cc:* lsr-cha...@ietf.org <mailto:lsr-cha...@ietf.org>
*Subject:* Re: [Lsr] LSR Presentation Slot Requests - IETF111

Speaking as WG member:

Hi Linda,

Even if you’ve added some IS-IS encodings, the draft still suffers from 
the fundamental problem of the previous draft. If you can’t rely on the 
A-ERs to consistently calculate an aggregated metric, how can you rely 
on all the routers in the IGP routing domain to use complex set of 
metrics to reach the least-loaded app server? Do we really want to talk 
about this again?

Thanks,
Acee

*From: *Linda Dunbar <linda.dun...@futurewei.com 
<mailto:linda.dun...@futurewei.com>>
*Date: *Monday, July 12, 2021 at 4:27 PM
*To: *Yingzhen Qu <yingzhen.i...@gmail.com 
<mailto:yingzhen.i...@gmail.com>>, "lsr@ietf.org <mailto:lsr@ietf.org>" 
<lsr@ietf.org <mailto:lsr@ietf.org>>
*Cc: *"lsr-cha...@ietf.org <mailto:lsr-cha...@ietf.org>" 
<lsr-cha...@ietf.org <mailto:lsr-cha...@ietf.org>>
*Subject: *RE: [Lsr] LSR Presentation Slot Requests - IETF111
*Resent-From: *<alias-boun...@ietf.org <mailto:alias-boun...@ietf.org>>
*Resent-To: *Acee Lindem <a...@cisco.com <mailto:a...@cisco.com>>, 
Christian Hopps <cho...@chopps.org <mailto:cho...@chopps.org>>, Yingzhen 
Qu <yingzhen.i...@gmail.com <mailto:yingzhen.i...@gmail.com>>
*Resent-Date: *Monday, July 12, 2021 at 4:27 PM

Yingzhen and LSR Chairs,

We need a 10 minutes slot at IETF111 to present 
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&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C492fc62171624e5792ea08d94636e9d9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637618023942568077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7f0TuUw7LVnzT2doHdN0CIJ4SinQP7KKzIUA61yBDrg%3D&reserved=0> 


Speaker: Linda Dunbar.

This draft adds the IS-IS extension to the 
draft-dunbar-lsr-5g-edge-compute-ospf-ext-04.

Thank you

Linda Dunbar

*From:* Lsr <lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org>> *On 
Behalf Of *Yingzhen Qu
*Sent:* Wednesday, June 30, 2021 4:00 PM
*To:* lsr@ietf.org <mailto:lsr@ietf.org>
*Cc:* lsr-cha...@ietf.org <mailto:lsr-cha...@ietf.org>
*Subject:* [Lsr] LSR Presentation Slot Requests - IETF111

Hi all,


The draft agenda for IETF111 has been posted: 
https://datatracker.ietf.org/meeting/111/agenda 
<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F111%2Fagenda&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C492fc62171624e5792ea08d94636e9d9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637618023942578032%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xI%2F46njm9a3I0qx7fDKRaULJ2qygqdDRT4QIBUtkBqQ%3D&reserved=0>. 


LSR will have one meeting session: Friday, July 30, 2021 16:00-18:00 
  Session III PDT

Please send slot requests to lsr-cha...@ietf.org 
<mailto:lsr-cha...@ietf.org>. Please include name of the presenter, 
pointer to the draft and time estimation including Q&A.

Thanks,

Yingzhen


_______________________________________________
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