> On Nov 16, 2024, at 08:45, [email protected] 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.
This would be a prime application for OSPF-GT. Another advantage is the one could use a sparse topology and remote neighbors with only the edge nodes forming adjacencies. The underlay for the topology wouldn’t need to be OSPF (e.g., it could be IS-IS). Thanks, Acee > > > Best Regards > Zongpeng Du > > [email protected] <mailto:[email protected]> & > [email protected] <mailto:[email protected]> > > From: Aijun Wang <mailto:[email protected]> > Date: 2024-11-15 20:23 > To: Acee Lindem <mailto:[email protected]> > CC: adrian <mailto:[email protected]>; lsr <mailto:[email protected]> > 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 <[email protected] > > <mailto:[email protected]>> wrote: > > > > Speaking as co-chair of LSR: > > > >> On Nov 15, 2024, at 06:22, Adrian Farrel <[email protected]> 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 <[email protected]> > >> Sent: 15 November 2024 02:18 > >> To: [email protected] > >> 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 > >> > >> -----邮件原件----- > >> 发件人: [email protected] [mailto:[email protected]] > >> 发送时间: 2024年11月15日 10:15 > >> 收件人: Gyan S. Mishra <[email protected]>; Aijun Wang > >> <[email protected]>; Changwang <[email protected]>; > >> Changwang Lin <[email protected]>; Gyan Mishra > >> <[email protected]>; Zhibo Hu <[email protected]> > >> 主题: 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 -- [email protected] > >> To unsubscribe send an email to [email protected] > >> > >> _______________________________________________ > >> Lsr mailing list -- [email protected] > >> To unsubscribe send an email to [email protected] > > > > > > _______________________________________________ > Lsr mailing list -- [email protected] <mailto:[email protected]> > To unsubscribe send an email to [email protected] <mailto:[email protected]>
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
