As tempted as I am to debate your assertions, we’re not going to the discuss this in LSR until the CATS WG is done with architecture so we are all evaluating solutions from the same baseline.
Thanks, Acee > On Nov 17, 2024, at 21:02, Aijun Wang <[email protected]> wrote: > > Hi, Joel: > > What I want to express is that, the nodes will eventually take both network > information, and computing information that attached to network, together. > The combined optimization calculation will certainly be local matter, but > should be done via the “the interaction between OSPF-GT instance and the OSPF > base instance”. Then, what’s the benefit to transport them via different > instances? > In our current proposal, the node has no interest/capabilities to parse the > associated information can just ignore them, there will be no churn on the > IGP convergences. > > We should also notices that adding another instance on the IGP nodes, will > also burden their pressure, and also the complexity of deployment within the > operator network. > > > Best Regards > > Aijun Wang > China Telecom > > 发件人: [email protected] <mailto:[email protected]> > [mailto:[email protected]] 代表 Joel Halpern > 发送时间: 2024年11月17日 13:04 > 收件人: Aijun Wang <[email protected] <mailto:[email protected]>> > 抄送: lsr <[email protected] <mailto:[email protected]>> > 主题: [Lsr] Re: New Version Notification for > draft-wang-lsr-network-computing-optimization-00.txt > > Aijun, I read the CATS aim rather differently. The ingress edge device gets > two sets of information. One set is the network information from the routing > protocol. The other set is the compute capabilities / metrics from the > compute services. The charter explicitly says that the process to combine > those two sets of information is a local matter. It seems quite a stretch to > go from their to claiming that if the two sets of information are come from > separate source, via separate channels, the effort will fail. > > Yours, > > Joel > > On 11/16/2024 10:23 AM, Aijun Wang wrote: >> Hi, Acee: >> >> If the OSPF-GT instance has no interaction with the OSPF base instance, then >> the CATS’s aim, that the combined optimization of network and compute >> information WILL NOT be achieved. >> >> Aijun Wang >> China Telecom >> >> >>> On Nov 16, 2024, at 22:25, Acee Lindem <[email protected]> >>> <mailto:[email protected]> wrote: >>> >>> >>> >>> >>>> On Nov 16, 2024, at 09:16, Aijun Wang <[email protected]> >>>> <mailto:[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] <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]
