[Lsr] Re: New Version Notification for draft-wang-lsr-network-computing-optimization-00.txt

[Aijun Wang]

Hi, Adrian: Yes, we will try to keep align with the discussion of architecture and functional in CATS WG. But, have some thoughts about the protocol extension may also have some good feedbacks for the design of architecture and functions in CATS. They can evolve together. Regarding to your responses for my concerns with OSPF-GT, Yes, I think you get my points.  But I don’t agree with your argument that tunnel can lead to the effect for “ so the complexity would be significantly reduced.” Tunnel is the forwarding plane. What I mentioned “the complex” is for the control plane—-because the router should correlate the network information and compute information together to find the optimal destination, putting these information in two different  OSPF instances will hinder the advantage of the CATS’s aim. Aijun Wang China Telecom On Nov 16, 2024, at 22:42, Adrian Farrel <adr...@olddog.co.uk> wrote:  This is all a bit CATS, but perhaps we should spell it out to understand the requirements?   The point is that the CATS Forwarder (the ingress edge) must select a remote compute service site based on knowledge about the capabilities and load of the available services at the sites and the network connectivity properties to those sites.   I think the point that Aijun makes is that, by separating the two uses of an IGP (one for edge-to-edge compute metric distribution, and one for in-network route generation) we make it more complex for the CATS Forwarder to select the best site and derive the best path to that site.   My personal opinion (so I suppose my CATS chair hat is not on), is that an appropriate approach for CATS is one that has tunnels (probably TE tunnels) between ingress edges and customer sites, so the complexity would be significantly reduced.   Another opinion (and CATS chair hat is now firmly on) is that this discussion is highly dependent on the architectural and functional discussions in CATS. It would be good to abstract the discussions from specific protocols and come to CATS to discuss what the requirements are and how the service might be delivered/realised without getting wrapped up in the protocol solutions.   Cheers, Adrian   From: Aijun Wang <wangai...@tsinghua.org.cn> Sent: 16 November 2024 14:16 To: duzongp...@foxmail.com Cc: Adrian Farrel <adr...@olddog.co.uk>; lsr@ietf.org; Lindem <acee.i...@gmail.com> Subject: Re: [Lsr] Re: New Version Notification for draft-wang-lsr-network-computing-optimization-00.txt   Hi, Zongpeng:   The concern for OSPF-GT proposal is that there will be complex communication mechanism between the OSPF-GT instance and the OSPF base instance. We have discussed such issues before.     Aijun Wang China Telecom On Nov 16, 2024, at 21:46, duzongp...@foxmail.com wrote:  Hi, Aijun,           I have checked that in this draft, https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-transport-instance/07/          One of the usecases is that 3.1. MEC Service Discovery            The followings are an incomplete list of the kind of information that    OSPF-GT can be used to advertise:       ...    *  Network resources are limited, such as computing power, storage.       The availability of such resources is dynamic, and OSPF-GT can be       used to populate such information, so applications can pick the       right location of such resources, hence improve user experience       and resource utilization.         Perhaps we can use the OSPF-GT as the way to prograte the computing information ?         However, it is stated as a way only for non-routing information.      Best Regards Zongpeng Du   duzongp...@foxmail.com & duzongp...@chinamobile.com    From: Aijun Wang Date: 2024-11-15 20:23 To: Acee Lindem CC: adrian; lsr Subject: [Lsr] Re: New Version Notification for draft-wang-lsr-network-computing-optimization-00.txt Hi, Acee and Adrian:   I noticed the CATS WG began just the use cases and architecture document and will follow the progress of works in CATS WG to update the proposed draft.   And I want to empathize also that current IGP based proposal will not “ compromise convergence for the "Normal business" of the IGP ”, only the nodes that updated, or the nodes want to utilize such information will calculate the optimal path based on the network and compute information. There will be also no LOOP in the forwarding plane, because the traffic will be tunneled to the optimal destination edge node.   Aijun Wang China Telecom   > On Nov 15, 2024, at 19:42, Acee Lindem <acee.i...@gmail.com> wrote: > > Speaking as co-chair of LSR: > >> On Nov 15, 2024, at 06:22, Adrian Farrel <adr...@olddog.co.uk> wrote: >> >> Hi, >> >> Speaking as co-chair of CATS. >> >> The CATS working group is still not ready for any protocol solutions work, although we are aware that a number of proposals have been made. >> >> At the moment we are still developing the architecture, requirements, and metrics. These are fundamentals that we need to resolve before it is appropriate to get behind any protocol solutions. > > That’s fine with us since we have a backlog of drafts to consider in LSR.  > >> >> However, it is worth noting that CATS is an edge function. That is, it does traffic steering not routing/forwarding within the network. One of the issues to be resolved is how to get the right compute metric information to the right places in the network without challenging other places to handle unwanted information. > > Right - it seems we’ve been all through this in the initial CATS discussions. When we do get to solutions, attaching this compute capacity information to the base topology LSAs and LSPs is definitely the wrong direction. > > >> >> In this context, many might apply caution to the use of an IGP because of the load it places on every node in the network even though most of those nodes do not need to see the compute traffic. It might be worrying that this load would compromise convergence for the "Normal business" of the IGP - namely to forward packets. > > Exactly. > > Thanks, > Acee > > >> >> It might be useful to look at the work done long ago in the L1VPN working group to use a separate instance of the IGP (in that case, the work was only done for OSPF) to distribute VPN membership information between remote peers at the edge of the network. This approach protects transit routers from the additional information and makes it just an edge function. See RFC 5252 and RFC 5523. >> >> Cheers, >> Adrian >> >> -----Original Message----- >> From: Aijun Wang <wangai...@tsinghua.org.cn> >> Sent: 15 November 2024 02:18 >> To: lsr@ietf.org >> Subject: [Lsr] 转发: New Version Notification for draft-wang-lsr-network-computing-optimization-00.txt >> >> Hi, All: >> >> We have submitted one document that proposes the IGP based solution for network-computing-combined optimization, which can apply to the scenarios that discussed within CATS WG. >> Feedbacks and comments are welcome. >> >> Aijun Wang >> China Telecom >> >> -----邮件原件----- >> 发件人: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] >> 发送时间: 2024年11月15日 10:15 >> 收件人: Gyan S. Mishra <gyan.s.mis...@verizon.com>; Aijun Wang <wang...@chinatelecom.cn>; Changwang <linchangwang.04...@h3c.com>; Changwang Lin <linchangwang.04...@h3c.com>; Gyan Mishra <gyan.s.mis...@verizon.com>; Zhibo Hu <huzh...@huawei.com> >> 主题: New Version Notification for draft-wang-lsr-network-computing-optimization-00.txt >> >> A new version of Internet-Draft >> draft-wang-lsr-network-computing-optimization-00.txt has been successfully submitted by Aijun Wang and posted to the IETF repository. >> >> Name:     draft-wang-lsr-network-computing-optimization >> Revision: 00 >> Title:    IGP based Network Computing Combined Optimization >> Date:     2024-11-15 >> Group:    Individual Submission >> Pages:    13 >> URL:      https://www.ietf.org/archive/id/draft-wang-lsr-network-computing-optimization-00.txt >> Status:   https://datatracker.ietf.org/doc/draft-wang-lsr-network-computing-optimization/ >> HTMLized: https://datatracker.ietf.org/doc/html/draft-wang-lsr-network-computing-optimization >> >> >> Abstract: >> >>  This document describes the scenario and procedures that can be used >>  to accomplish the IGP based network and computing combined >>  optimization within the IS-IS or OSPF domain. >> >> >> >> The IETF Secretariat >> >> >> >> _______________________________________________ >> Lsr mailing list -- lsr@ietf.org >> To unsubscribe send an email to lsr-le...@ietf.org >> >> _______________________________________________ >> Lsr mailing list -- lsr@ietf.org >> To unsubscribe send an email to lsr-le...@ietf.org > >   _______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org _______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org _______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org

_______________________________________________
Lsr mailing list -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org