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" <[e-mail]>]

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) <[e-mail]>
> *Sent:* Tuesday, July 13, 2021 2:46 PM
> *To:* Linda Dunbar <[e-mail]>; Yingzhen Qu 
> <[e-mail]>; [e-mail]
> *Cc:* [e-mail]
> *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 <[e-mail] 
> <mailto:[e-mail]>>
> *Date: *Tuesday, July 13, 2021 at 3:42 PM
> *To: *Acee Lindem <[e-mail] <mailto:[e-mail]>>, Yingzhen Qu 
> <[e-mail] <mailto:[e-mail]>>, 
> "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
> *Cc: *"[e-mail] <mailto:[e-mail]>" 
> <[e-mail] <mailto:[e-mail]>>
> *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) <[e-mail] <mailto:[e-mail]>>
> *Sent:* Tuesday, July 13, 2021 2:24 PM
> *To:* Linda Dunbar <[e-mail] 
> <mailto:[e-mail]>>; Yingzhen Qu 
> <[e-mail] <mailto:[e-mail]>>; [e-mail] 
> <mailto:[e-mail]>
> *Cc:* [e-mail] <mailto:[e-mail]>
> *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 <[e-mail] 
> <mailto:[e-mail]>>
> *Date: *Tuesday, July 13, 2021 at 1:23 PM
> *To: *Acee Lindem <[e-mail] <mailto:[e-mail]>>, Yingzhen Qu 
> <[e-mail] <mailto:[e-mail]>>, 
> "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
> *Cc: *"[e-mail] <mailto:[e-mail]>" 
> <[e-mail] <mailto:[e-mail]>>
> *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) <[e-mail] <mailto:[e-mail]>>
> *Sent:* Monday, July 12, 2021 7:06 PM
> *To:* Linda Dunbar <[e-mail] 
> <mailto:[e-mail]>>; Yingzhen Qu 
> <[e-mail] <mailto:[e-mail]>>; [e-mail] 
> <mailto:[e-mail]>
> *Cc:* [e-mail] <mailto:[e-mail]>
> *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 <[e-mail] 
> <mailto:[e-mail]>>
> *Date: *Monday, July 12, 2021 at 5:41 PM
> *To: *Acee Lindem <[e-mail] <mailto:[e-mail]>>, Yingzhen Qu 
> <[e-mail] <mailto:[e-mail]>>, 
> "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
> *Cc: *"[e-mail] <mailto:[e-mail]>" 
> <[e-mail] <mailto:[e-mail]>>
> *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) <[e-mail] <mailto:[e-mail]>>
> *Sent:* Monday, July 12, 2021 4:04 PM
> *To:* Linda Dunbar <[e-mail] 
> <mailto:[e-mail]>>; Yingzhen Qu 
> <[e-mail] <mailto:[e-mail]>>; [e-mail] 
> <mailto:[e-mail]>
> *Cc:* [e-mail] <mailto:[e-mail]>
> *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 <[e-mail] 
> <mailto:[e-mail]>>
> *Date: *Monday, July 12, 2021 at 4:27 PM
> *To: *Yingzhen Qu <[e-mail] 
> <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" 
> <[e-mail] <mailto:[e-mail]>>
> *Cc: *"[e-mail] <mailto:[e-mail]>" 
> <[e-mail] <mailto:[e-mail]>>
> *Subject: *RE: [Lsr] LSR Presentation Slot Requests - IETF111
> *Resent-From: *<[e-mail] <mailto:[e-mail]>>
> *Resent-To: *Acee Lindem <[e-mail] <mailto:[e-mail]>>, 
> Christian Hopps <[e-mail] <mailto:[e-mail]>>, Yingzhen 
> Qu <[e-mail] <mailto:[e-mail]>>
> *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 <[e-mail] <mailto:[e-mail]>> *On 
> Behalf Of *Yingzhen Qu
> *Sent:* Wednesday, June 30, 2021 4:00 PM
> *To:* [e-mail] <mailto:[e-mail]>
> *Cc:* [e-mail] <mailto:[e-mail]>
> *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 [e-mail] 
> <mailto:[e-mail]>. Please include name of the presenter, 
> pointer to the draft and time estimation including Q&A.
> 
> Thanks,
> 
> Yingzhen
> 
> 
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>