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> Date: Tuesday, July 13, 2021 at 1:23 PM To: Acee Lindem <a...@cisco.com>, Yingzhen Qu <yingzhen.i...@gmail.com>, "lsr@ietf.org" <lsr@ietf.org> Cc: "lsr-cha...@ietf.org" <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> Sent: Monday, July 12, 2021 7:06 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) 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%7Cc231cf9bf5a14a7404d908d945920311%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637617315695998528%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EpFFhfCXHM33xhcq7QbqVJGoPpvx3hc%2Fbu80zlsmOdo%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%7Cc231cf9bf5a14a7404d908d945920311%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637617315696008484%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=F5iGeQ3x%2Fj50Ga1UjXcCDOiTa%2Fy4e%2FBNObkRR9OinIQ%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
