> On Nov 16, 2024, at 09:16, Aijun Wang <[email protected]> wrote: > > 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.
I guess this shouldn’t surprise me but this is completely wrong. The OSPF-GT instance forms separate adjacency and has no interaction with the OSPF instance. To assure the information is current, OSPF-GT instances can either form a direct remote neighbor adjacency or by assuring the neighbor is reachable in the OSPF-GT topology for usage. Acee > > > Aijun Wang > China Telecom > >> On Nov 16, 2024, at 21:46, [email protected] >> <mailto:[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. >> >> 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] >> >> <mailto:[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] >> >> <mailto:[email protected]>> >> >> Sent: 15 November 2024 02:18 >> >> To: [email protected] <mailto:[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]> >> >> [mailto:[email protected]] >> >> 发送时间: 2024年11月15日 10:15 >> >> 收件人: Gyan S. Mishra <[email protected] >> >> <mailto:[email protected]>>; Aijun Wang <[email protected] >> >> <mailto:[email protected]>>; Changwang <[email protected] >> >> <mailto:[email protected]>>; Changwang Lin >> >> <[email protected] <mailto:[email protected]>>; Gyan >> >> Mishra <[email protected] <mailto:[email protected]>>; >> >> Zhibo Hu <[email protected] <mailto:[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] <mailto:[email protected]> >> >> To unsubscribe send an email to [email protected] >> >> <mailto:[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] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[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]
