[{"author": "Adrian Farrel", "text": "yes<br/>", "time": "2022-03-22T09:00:21Z"}, {"author": "Ketan Talaulikar", "text": "Jeffrey's volume is very low for me even after moving the slider all the way to the right<br/>", "time": "2022-03-22T09:03:28Z"}, {"author": "Shigeya Suzuki", "text": "very low for me too.<br/>", "time": "2022-03-22T09:04:13Z"}, {"author": "Ketan Talaulikar", "text": "great!<br/>", "time": "2022-03-22T09:04:28Z"}, {"author": "Chris Lemmons", "text": "Much better!<br/>", "time": "2022-03-22T09:04:28Z"}, {"author": "Cheng Li", "text": "much better now<br/>", "time": "2022-03-22T09:04:32Z"}, {"author": "Cheng Li", "text": "I can not see the deck<br/>", "time": "2022-03-22T09:08:15Z"}, {"author": "Cheng Li", "text": "just shows that a ned deck is being shared<br/>", "time": "2022-03-22T09:08:31Z"}, {"author": "Chris Lemmons", "text": "I have the same problem. I reloaded to no avail.<br/>", "time": "2022-03-22T09:09:02Z"}, {"author": "Chris Lemmons", "text": "... and it loads. :)<br/>", "time": "2022-03-22T09:09:10Z"}, {"author": "Cheng Li", "text": "now is good<br/>", "time": "2022-03-22T09:09:19Z"}, {"author": "Aijun Wang", "text": "can the speaker take off the mask?<br/>", "time": "2022-03-22T09:09:55Z"}, {"author": "Meetecho", "text": "That message appears while the presenter is choosing the slide deck to share, nothing to worry about :)<br/>", "time": "2022-03-22T09:09:56Z"}, {"author": "Meetecho", "text": "Aijun Wang: masks are mandatory here<br/>", "time": "2022-03-22T09:10:10Z"}, {"author": "Cheng Li", "text": "thank you @meetecho<br/>", "time": "2022-03-22T09:10:34Z"}, {"author": "Shraddha Hegde", "text": "For me voice is very low. can hardly hear<br/>", "time": "2022-03-22T09:11:08Z"}, {"author": "Meetecho", "text": "Is audio better now?<br/>", "time": "2022-03-22T09:11:50Z"}, {"author": "John Scudder", "text": "yes, from my pov<br/>", "time": "2022-03-22T09:12:05Z"}, {"author": "Shraddha Hegde", "text": "slightly better but still low<br/>", "time": "2022-03-22T09:12:08Z"}, {"author": "Deb Cooley", "text": "He's pretty far away from the mic... quiet in the room too.<br/>", "time": "2022-03-22T09:12:13Z"}, {"author": "Ketan Talaulikar", "text": "yes, the volume is low. maybe more proximity to the mike ? :-)<br/>", "time": "2022-03-22T09:12:22Z"}, {"author": "Cheng Li", "text": "closer to the mic can help<br/>", "time": "2022-03-22T09:12:41Z"}, {"author": "Meetecho", "text": "Maybe speaking closer to the mic would help, we risk increasing the gain too much which could be an issue when interacting with remote speakers<br/>", "time": "2022-03-22T09:13:04Z"}, {"author": "Haomian Zheng", "text": "we are now aware the power of mask:)<br/>", "time": "2022-03-22T09:13:25Z"}, {"author": "cabo", "text": "Protip: get a dynamics compressor (\"booster\") for your listening device (Mac: Try SoundSource).<br/>", "time": "2022-03-22T09:14:16Z"}, {"author": "Shigeya Suzuki", "text": "cabo: Good tip. Thanks. It works. Now, I have to buy another Rogue Amobeba software... :)<br/>", "time": "2022-03-22T09:19:40Z"}, {"author": "Rich Salz", "text": "PLEASE STATE YOUR NAME WHEN SPEAKING AT THE MIC<br/>", "time": "2022-03-22T09:21:24Z"}, {"author": "Jim Uttaro", "text": "Pls provide an example of a huge scientific application<br/>", "time": "2022-03-22T09:21:36Z"}, {"author": "Joel Halpern", "text": "Also, in room folks should use the queue button.<br/>", "time": "2022-03-22T09:21:42Z"}, {"author": "Tony Li", "text": "No, CNC is not Computer Numerical Control<br/>", "time": "2022-03-22T09:24:24Z"}, {"author": "John Scudder", "text": "Compute+Networking Convergence<br/>", "time": "2022-03-22T09:24:26Z"}, {"author": "Dhruv Dhody", "text": "computing and network convergence (CNC) <br/>", "time": "2022-03-22T09:24:30Z"}, {"author": "Deb Cooley", "text": "It is in the slides...<br/>", "time": "2022-03-22T09:24:36Z"}, {"author": "Joel Halpern", "text": "He stated on his slide that it is in ITU-T SG-13.<br/>", "time": "2022-03-22T09:24:39Z"}, {"author": "Cheng Li", "text": "This is the ITU-T work<br/>", "time": "2022-03-22T09:24:48Z"}, {"author": "Yuexia Fu", "text": "CNC is computing and network convergence, in ITU-T sg13<br/>", "time": "2022-03-22T09:25:10Z"}, {"author": "Dirk Trossen", "text": "Found this at ITU website <a href=\"https://www.itu.int/md/T17-SG13-211129-TD-WP1-0953\" rel=\"nofollow\">https://www.itu.int/md/T17-SG13-211129-TD-WP1-0953</a><br/>", "time": "2022-03-22T09:26:04Z"}, {"author": "Dirk Kutscher", "text": "thanks<br/>", "time": "2022-03-22T09:26:41Z"}, {"author": "Dirk Trossen", "text": "Hmm, apologies, realized you need TIES access for it (i.e. ITU account) - maybe there could be some open document the presenters could share on CNC?<br/>", "time": "2022-03-22T09:26:57Z"}, {"author": "Joel Halpern", "text": "Chairs should unclose the queue.<br/>", "time": "2022-03-22T09:28:13Z"}, {"author": "Joel Halpern", "text": "Thanks.<br/>", "time": "2022-03-22T09:28:33Z"}, {"author": "Yuexia Fu", "text": "yes, documents on CNC will be shared later via mailing list<br/>", "time": "2022-03-22T09:28:40Z"}, {"author": "Dirk Kutscher", "text": "It would be useful to understand the relationship of these systems (MEC, CNC) with existing transport layer security and trust infrastructure for that. I think this was Erik's questions as well...<br/>", "time": "2022-03-22T09:28:44Z"}, {"author": "John Scudder", "text": "Chairs, queue is again closed. (Did you both click the toggle?)<br/>", "time": "2022-03-22T09:29:20Z"}, {"author": "Rich Salz", "text": "UE = user equipment?<br/>", "time": "2022-03-22T09:33:33Z"}, {"author": "Dean Bogdanovi\u0107", "text": "yes<br/>", "time": "2022-03-22T09:33:38Z"}, {"author": "Cheng Li", "text": "yes<br/>", "time": "2022-03-22T09:33:49Z"}, {"author": "Tony Li", "text": "i.e. mobile phone<br/>", "time": "2022-03-22T09:33:52Z"}, {"author": "Pete Resnick", "text": "Perhaps a dumb question (I am from the upper layers and the air is thin and makes me stupid), but is there some sort of authorization model so that an edge can indicate whether or not it will provide compute services? I didn't see anything in the current drafts.<br/>", "time": "2022-03-22T09:33:54Z"}, {"author": "Rich Salz", "text": "It would appear to be the contract you signed with your phone provider.<br/>", "time": "2022-03-22T09:34:36Z"}, {"author": "Tony Li", "text": "I think what you really mean is service discovery and yes, that should be part of it.<br/>", "time": "2022-03-22T09:35:02Z"}, {"author": "cabo", "text": "(And the UE/App also needs to authorize (\"trust\") the edge to provide the service.)<br/>", "time": "2022-03-22T09:35:03Z"}, {"author": "Dean Bogdanovi\u0107", "text": "anytime you talk to MNOs, they forget to mention SIMs and the AAA SIM provides<br/>", "time": "2022-03-22T09:35:11Z"}, {"author": "Joel Halpern", "text": "@Pete that is a good quesiton.&nbsp;&nbsp;If one is trying to solve the useful quesiton of how the application asks for services from the network.&nbsp;&nbsp;This seems (but I am not sure) to be something else.<br/>", "time": "2022-03-22T09:35:15Z"}, {"author": "Marie-Jose Montpetit", "text": "@ Pete: there is an edge discovery draft in COIN RG (it needs updating but some functionality is there)<br/>", "time": "2022-03-22T09:35:18Z"}, {"author": "Cheng Li", "text": "it will be a general requirement for MEC, even for services providing, but it worth to be discussed.<br/>", "time": "2022-03-22T09:36:13Z"}, {"author": "Dirk Kutscher", "text": "IMO, it's rather similar to todays edge data center deployments of OTT caches. The operator would decide to run such functions and then may route UE requests to those instances.<br/>", "time": "2022-03-22T09:36:22Z"}, {"author": "Carlos Bernardos", "text": "I wonder if mobility issues (and associated protocols) are also in scope. I think there are scenarios where routing alone would not be sufficient<br/>", "time": "2022-03-22T09:36:22Z"}, {"author": "Mike McBride", "text": "We've had had edge DATA discovery drafts in coin but not edge device discovery unless perhaps there is now both.<br/>", "time": "2022-03-22T09:36:28Z"}, {"author": "Pete Resnick", "text": "So service discovery will include some concept of permission (in both directions). OK, that makes sense.<br/>", "time": "2022-03-22T09:36:31Z"}, {"author": "Tony Li", "text": "@Carlos: Yes, absolutely. See Linda's draft.<br/>", "time": "2022-03-22T09:37:04Z"}, {"author": "Joel Halpern", "text": "@Carlos - if this were handled as an overlay question I think mobility could be part of it.&nbsp;&nbsp;But trying to make underlay routing do any of this is a mistake.<br/>", "time": "2022-03-22T09:37:22Z"}, {"author": "Carlos Bernardos", "text": "@Tony: thanks<br/>", "time": "2022-03-22T09:37:31Z"}, {"author": "Dirk Trossen", "text": "@Carlos indeed, routing in the light of mobility is clearly in scope - also looking at the use cases (wait for next slide)<br/>", "time": "2022-03-22T09:37:37Z"}, {"author": "Carlos Bernardos", "text": "@Joel: exactly, that\u2019s my point. I don\u2019t think routing can do that<br/>", "time": "2022-03-22T09:37:53Z"}, {"author": "Mike McBride", "text": "@Dirk. Sounds like this could be used as a high performance DLT network.<br/>", "time": "2022-03-22T09:38:26Z"}, {"author": "Carlos Bernardos", "text": "@Dirk: I\u2019m not sure routing might be the solution for all the scenarios involving mobility. I think for some we might need routing+mobility solutions<br/>", "time": "2022-03-22T09:38:35Z"}, {"author": "Rich Salz", "text": "DLT?<br/>", "time": "2022-03-22T09:38:35Z"}, {"author": "Mike McBride", "text": "Blockchain. DLT=distributed ledger technologies<br/>", "time": "2022-03-22T09:38:53Z"}, {"author": "Cullen Jennings", "text": "I think the explanation of this AR/VR use case is very good. <br/>", "time": "2022-03-22T09:38:59Z"}, {"author": "Dirk Kutscher", "text": "I hope not ;-)<br/>", "time": "2022-03-22T09:39:04Z"}, {"author": "Carlos Bernardos", "text": "and I guess ALTO might fit into the picture here. For what\u2019s being presented for the AR/VR use case, no?<br/>", "time": "2022-03-22T09:39:11Z"}, {"author": "Rich Salz", "text": "@Mike, no comment other than thanks.<br/>", "time": "2022-03-22T09:39:14Z"}, {"author": "Dirk Trossen", "text": "@Carlos didn't suggest that routing alone solves it, particularly when you want service, not just client mobility. I said 'routing in the light of mobilty'.<br/>", "time": "2022-03-22T09:39:37Z"}, {"author": "Carlos Bernardos", "text": "@Dirk: ok, ok<br/>", "time": "2022-03-22T09:40:03Z"}, {"author": "Cullen Jennings", "text": "I lost audio<br/>", "time": "2022-03-22T09:40:09Z"}, {"author": "Ketan Talaulikar", "text": "same here<br/>", "time": "2022-03-22T09:40:16Z"}, {"author": "Dean Bogdanovi\u0107", "text": "no audio in the room as well<br/>", "time": "2022-03-22T09:40:37Z"}, {"author": "Meetecho", "text": "Maybe mics ran out of juice, pinging AV team<br/>", "time": "2022-03-22T09:40:57Z"}, {"author": "John Scudder", "text": "I think speaker is offsite<br/>", "time": "2022-03-22T09:41:23Z"}, {"author": "John Scudder", "text": "fixed now<br/>", "time": "2022-03-22T09:41:47Z"}, {"author": "Dirk Trossen", "text": "@Carlos no problem, didn't mean any offense. My point is that if you want to ensure mobility on both ends (client and service), any routing decision (to a possible new service instance) must be complemented by ensuring the mobility of any transaction (dyncast calls this 'affinity') since routing to a new service instance may break ongoing transactions.<br/>", "time": "2022-03-22T09:42:20Z"}, {"author": "Dirk Trossen", "text": "so somehow you will need coordinate the decision to steer traffic to a new service instance with ensuring that the client may continue its ongoing transaction (or decide to simply not re-route)<br/>", "time": "2022-03-22T09:43:16Z"}, {"author": "Christian Hopps", "text": "will there be a time to question the entire concept?<br/>", "time": "2022-03-22T09:44:51Z"}, {"author": "Dirk Kutscher", "text": "There is a discussion slot at the end of the session.<br/>", "time": "2022-03-22T09:45:18Z"}, {"author": "Tony Li", "text": "There's open discussion later<br/>", "time": "2022-03-22T09:45:20Z"}, {"author": "John Scudder", "text": "@Chris, end of session<br/>", "time": "2022-03-22T09:45:24Z"}, {"author": "Christian Hopps", "text": "great thanks :)<br/>", "time": "2022-03-22T09:46:12Z"}, {"author": "Luis Contreras", "text": "@Carlos: regarding ALTO, certainly it can play a role on the overall idea of compute awareness, but differetly from routing, so more in the line of exposing compute capabilities available in the network (see for example draft-contreras-alto-service-edge)<br/>", "time": "2022-03-22T09:46:40Z"}, {"author": "Cheng Li", "text": "as my understanding, it would based on service, a service will be identified by an anycast address<br/>", "time": "2022-03-22T09:46:48Z"}, {"author": "Tony Li", "text": "This doesn't sound like a clarifying question...<br/>", "time": "2022-03-22T09:47:33Z"}, {"author": "Carlos Bernardos", "text": "@Dirk: thanks for the clarification. I think this is an interesting problem<br/>", "time": "2022-03-22T09:47:36Z"}, {"author": "Carlos Bernardos", "text": "@Luis:&nbsp;&nbsp;OK, I\u2019ll check the draft<br/>", "time": "2022-03-22T09:47:51Z"}, {"author": "Aijun Wang", "text": "ALTO can't let every router within the domain to select the best MEC server<br/>", "time": "2022-03-22T09:49:14Z"}, {"author": "Zhenbin Li", "text": "@Wim Regarding your question, please to refer to the following presentation. It may be not necessary application-based. It can use the anycast IP address for the location of the application.<br/>", "time": "2022-03-22T09:51:27Z"}, {"author": "Marco Liebsch", "text": "regarding the previous comment: 3GPP solves the discussed problem up to UPF, more is needed for complete e2e traffic treatment over the N6 reference point. Just one pointer where this has been discussed: <a href=\"https://datatracker.ietf.org/doc/html/draft-fattore-dmm-n6-cpdp-trafficsteering\" rel=\"nofollow\">https://datatracker.ietf.org/doc/html/draft-fattore-dmm-n6-cpdp-trafficsteering</a><br/>", "time": "2022-03-22T09:51:40Z"}, {"author": "Zhenbin Li", "text": "The CAN dyncast work is to depend on the network device to steering traffic other than the UPF..<br/>", "time": "2022-03-22T09:53:14Z"}, {"author": "Zongpeng Du", "text": "3GPP is also researching the distributed architecture now. Perhaps, the position of UPF in future will be much lower in the network than now.<br/>", "time": "2022-03-22T09:54:39Z"}, {"author": "Christian Hopps", "text": "So use Anycast to find the nearest alive load balancer, now it's not a single point of failure and it's multiple site aware.<br/>", "time": "2022-03-22T09:55:35Z"}, {"author": "Pete Resnick", "text": "Traditional DNS might be a problem, but DNS-SD might be adaptable for this.<br/>", "time": "2022-03-22T09:55:51Z"}, {"author": "Pete Resnick", "text": "I don't know it well enough to say for sure.<br/>", "time": "2022-03-22T09:56:33Z"}, {"author": "Dirk Trossen", "text": "@Pete Peng is pointing out the dynamicity of possible relations, so any indirection step adds latency when wanting to make decisions at high frequencies (e.g., due to load changes, mobility).<br/>", "time": "2022-03-22T09:57:17Z"}, {"author": "Daniel Bernier", "text": "one elephant in the room I think is expecting that edge computing applications will rely solely on DNS or equivalent. Current development work show that it is becoming tighter with patterns like service meshes in cloud with application traffic routing logic (ref envoy sidecars or equivalent). <br/>So applications are getting smarter and smarter at optimizing traffic routing between client and server. <br/>However, as per Wim's comment, the application might know where its best edge is from a workload perspective but mobile UP (gNobe to UPF mapping) might not necessarily be there.<br/>", "time": "2022-03-22T09:57:22Z"}, {"author": "David Oran", "text": "Question: This seems to assume conventional non-distributed applications just running at the edge. what about modern frameworks like Sapphire? and Ray?<br/>", "time": "2022-03-22T09:58:56Z"}, {"author": "Christian Hopps", "text": "hmm i just lost all AV.. this happened yesterday to me too, it was my side <br/>", "time": "2022-03-22T09:58:59Z"}, {"author": "Zongpeng Du", "text": "Load Balancer in this Layer 3 is explored in dyncast.<br/>In dyncast,&nbsp;&nbsp;the network should recognize the service ID (anycast IP) of the packet.<br/>The service ID is the destination address of the IP packet, It kind of contains some service information.<br/>", "time": "2022-03-22T09:59:26Z"}, {"author": "Pete Resnick", "text": "@Dirk: Understood, but I think DNS-SD or something else like Bonjour might have the anycast (or at least multicast) and dynamic properties that you need. And they are (as I understand it) direct to the device, not indirect.<br/>", "time": "2022-03-22T10:01:29Z"}, {"author": "Pete Resnick", "text": "It may not fit, but it should at least be examined to see if it it useful or informative.<br/>", "time": "2022-03-22T10:02:15Z"}, {"author": "cabo", "text": "(Speaker confused by room echo?)<br/>", "time": "2022-03-22T10:02:31Z"}, {"author": "Cheng Li", "text": "good idea<br/>", "time": "2022-03-22T10:02:33Z"}, {"author": "John Scudder", "text": "echo from the room is pretty awful :-(<br/>", "time": "2022-03-22T10:03:36Z"}, {"author": "Dirk Trossen", "text": "@Pete I would say that this should be captured in a more detailed gap analysis - so yes, agree.<br/>", "time": "2022-03-22T10:03:57Z"}, {"author": "Pete Resnick", "text": "@meetecho: People reporting echo problems.<br/>", "time": "2022-03-22T10:04:00Z"}, {"author": "Meetecho", "text": "Checking<br/>", "time": "2022-03-22T10:04:20Z"}, {"author": "Pete Resnick", "text": "@Dirk: :thumbsup:<br/>", "time": "2022-03-22T10:04:23Z"}, {"author": "Meetecho", "text": "Is it a problem of echo in the venue, or for remotes? We checked and it sounds fine here<br/>", "time": "2022-03-22T10:05:39Z"}, {"author": "Pete Resnick", "text": "Remote. See John Scudder's comment above.<br/>", "time": "2022-03-22T10:06:07Z"}, {"author": "Cullen Jennings", "text": "problem for remote<br/>", "time": "2022-03-22T10:06:10Z"}, {"author": "Aijun Wang", "text": "The drawback of load balance based solution has been analyzed<br/>", "time": "2022-03-22T10:06:24Z"}, {"author": "Cheng Li", "text": "agree with pete and Dirk, it can be captured in in gap analysis future.<br/>", "time": "2022-03-22T10:06:33Z"}, {"author": "David Oran", "text": "For the state of the art on L4 LB, check <a href=\"https://dl.acm.org/doi/10.1145/3123878.3132012\" rel=\"nofollow\">https://dl.acm.org/doi/10.1145/3123878.3132012</a><br/>", "time": "2022-03-22T10:06:52Z"}, {"author": "Tony Li", "text": "I'm getting a lot of clipping on plosives.&nbsp;&nbsp;Too much gain?<br/>", "time": "2022-03-22T10:07:04Z"}, {"author": "Mat Ford", "text": "Application layer invisible to L7 too presumably if apps running over e.g. QUIC<br/>", "time": "2022-03-22T10:07:27Z"}, {"author": "Deb Cooley", "text": "the presenter is remote.<br/>", "time": "2022-03-22T10:07:28Z"}, {"author": "Meetecho", "text": "I've reduced the gain from the room a bit, please let me know if that helps (we can't reduce the remote speaker volume instead)<br/>", "time": "2022-03-22T10:07:33Z"}, {"author": "Pete Resnick", "text": "Yes, Shraddha is speaking a bit close to her mic it sounds like.<br/>", "time": "2022-03-22T10:07:39Z"}, {"author": "Christian Hopps", "text": "Wouldn't a L7 load balancer be working hand in hand with the appliication itself, so deep packet inspection isn't needed.<br/>", "time": "2022-03-22T10:07:42Z"}, {"author": "Meetecho", "text": "Yes the presenter is remote, but played out loud in the room, so the mics there capture the remote audio and can cause a bit of echo<br/>", "time": "2022-03-22T10:07:56Z"}, {"author": "Cullen Jennings", "text": "@meet echo - yes that helped<br/>", "time": "2022-03-22T10:08:01Z"}, {"author": "Adrian Farrel", "text": "@DaveO The question for me is whether this needs to be solved at the transport layer or at a lower layer. Doesn't it depend on the \"scope\" of the transactions?<br/>", "time": "2022-03-22T10:08:17Z"}, {"author": "Meetecho", "text": "Thanks Cullen!<br/>", "time": "2022-03-22T10:08:19Z"}, {"author": "David Oran", "text": "@Adrian - this is a \"cross layer\" problem, for a different take on how to decompose this check out <a href=\"https://conferences.sigcomm.org/acm-icn/2019/proceedings/icn19-16.pdf\" rel=\"nofollow\">https://conferences.sigcomm.org/acm-icn/2019/proceedings/icn19-16.pdf</a><br/>", "time": "2022-03-22T10:09:47Z"}, {"author": "Zongpeng Du", "text": "agree, there are some tradeoffs here<br/>", "time": "2022-03-22T10:10:35Z"}, {"author": "Zongpeng Du", "text": "Layer3 load balancer(a router) can obtain the network information easily, and more is closer to the user. The whole network can work as a distributed virtual Load Balancer.<br/>", "time": "2022-03-22T10:12:43Z"}, {"author": "Christian Hopps", "text": "it doesn't scale<br/>", "time": "2022-03-22T10:12:58Z"}, {"author": "Lars Eggert", "text": "i'm trying to understand if there is anything missing from current lbs that would prevent their use as-is? other than there is for market reasons no interop standard between different lbs?<br/>", "time": "2022-03-22T10:13:05Z"}, {"author": "Joel Halpern", "text": "@Chris - and injecting all of this into routing does scale?&nbsp;&nbsp;No.<br/>", "time": "2022-03-22T10:13:24Z"}, {"author": "Daniel Bernier", "text": "so UE anchoring to UPF needs to happen first<br/>", "time": "2022-03-22T10:13:32Z"}, {"author": "Christian Hopps", "text": "No that is my point<br/>", "time": "2022-03-22T10:13:32Z"}, {"author": "cabo", "text": "LBs are inside the application's security bubble.<br/>", "time": "2022-03-22T10:13:34Z"}, {"author": "Christian Hopps", "text": "@joel, this entire concept being presented here doesn't scale<br/>", "time": "2022-03-22T10:13:45Z"}, {"author": "Tony Li", "text": "As I understand it, session persistence across migration isn't covered<br/>", "time": "2022-03-22T10:13:51Z"}, {"author": "Tony Li", "text": "@Chris why not?<br/>", "time": "2022-03-22T10:14:09Z"}, {"author": "Dirk Trossen", "text": "@Lars I wonder how to coordinate the LBs if you mix and match vendors. Isn't this related to what&nbsp;&nbsp;CAN proposes, namely address the needed signaling of metric information?<br/>", "time": "2022-03-22T10:14:26Z"}, {"author": "John Scudder", "text": "@tli It wasn't clear to me how hard of a requirement session persistence was. <br/>", "time": "2022-03-22T10:14:38Z"}, {"author": "Christian Hopps", "text": "Each application may have a different definition of \"resources\" these then have to be boiled down into a single topology<br/>", "time": "2022-03-22T10:14:42Z"}, {"author": "Christian Hopps", "text": "Network Aware Computing (NAC! :) does scale<br/>", "time": "2022-03-22T10:15:04Z"}, {"author": "John Scudder", "text": "It seems impossible to satisfy that requirement simultaneously with the latency requirement<br/>", "time": "2022-03-22T10:15:05Z"}, {"author": "Joel Halpern", "text": "@chris unless I have confused myself, viewing this as an overlay service that uses encapsulations (LISP, SFC, NVO3, ...) allows one to decompose and scale suitably.&nbsp;&nbsp;The ingress edge can include load balancer logic.<br/>", "time": "2022-03-22T10:15:13Z"}, {"author": "Lars Eggert", "text": "@dirk exactly. but lb vendors have no incentive to interop?<br/>", "time": "2022-03-22T10:15:16Z"}, {"author": "Christian Hopps", "text": "damn lost the AV again.. brb<br/>", "time": "2022-03-22T10:15:20Z"}, {"author": "Zhenbin Li", "text": "I do not know how the application layer or the transport layer to learn the network status to steering traffic. For example, the packet is forwarded in the network take the shorted path. There can be other path with light load. How can the application/transport layer detect it and make the network steer to the path?<br/>", "time": "2022-03-22T10:15:21Z"}, {"author": "David Oran", "text": "Another fairly deep question is whether the interests of the organization deploying the application and the organization providing the network connectivity are aligned. Google doesn't worry about this because they are both.<br/>", "time": "2022-03-22T10:15:34Z"}, {"author": "Tony Li", "text": "I agree with Joel<br/>", "time": "2022-03-22T10:15:38Z"}, {"author": "Tony Li", "text": "That's why all of the UPFs have to have common state.<br/>", "time": "2022-03-22T10:16:18Z"}, {"author": "Cullen Jennings", "text": "where did Jeff tell us to look ? I missed it<br/>", "time": "2022-03-22T10:17:00Z"}, {"author": "John Scudder", "text": "What did Jeff just cite as a place where the problems have been solved?<br/>", "time": "2022-03-22T10:17:03Z"}, {"author": "Dirk Trossen", "text": "@Tony so all LBs are same vendor -&gt; vendor lock in?<br/>", "time": "2022-03-22T10:17:05Z"}, {"author": "Joel Halpern", "text": "Jeff is pointing at ALTO.<br/>", "time": "2022-03-22T10:17:13Z"}, {"author": "John Scudder", "text": "thanks<br/>", "time": "2022-03-22T10:17:19Z"}, {"author": "Tony Li", "text": "No, the point is that we need a standardized LB protocol<br/>", "time": "2022-03-22T10:17:26Z"}, {"author": "Christian Hopps", "text": "Ah, the overlay is an interesting idea, that is using networking as the LB transport I guess.<br/>", "time": "2022-03-22T10:17:42Z"}, {"author": "Dirk Trossen", "text": "@Tony my point of the second question?!<br/>", "time": "2022-03-22T10:17:49Z"}, {"author": "Christian Hopps", "text": "The key thing I have a problem with is the current set of drafts I'm seeing where the compute resources are being shoved into the underlay networking layer.<br/>", "time": "2022-03-22T10:18:32Z"}, {"author": "Rich Salz", "text": "PLEASE STATE YOUR NAME AT THE MIC LINE<br/>", "time": "2022-03-22T10:18:36Z"}, {"author": "Zongpeng Du", "text": "After this layer3 Load balancer, the packet will be put into a tunnel to the Egress PE. So the solution can scale IMO.<br/>", "time": "2022-03-22T10:18:50Z"}, {"author": "Tony Li", "text": "@Chris and that's definitely a mistake.<br/>", "time": "2022-03-22T10:18:55Z"}, {"author": "David Oran", "text": "@Zhengbin: isn't what you describe&nbsp;&nbsp;exactly what Google's B4 does? (<a href=\"https://research.google/pubs/pub47191/\" rel=\"nofollow\">https://research.google/pubs/pub47191/</a>)<br/>", "time": "2022-03-22T10:19:15Z"}, {"author": "Christian Hopps", "text": "@Tony, right, I think my zeal for rtying to shut that down may have blinded me to some more novel ideas like using an overlay as LB transport. <br/>", "time": "2022-03-22T10:19:45Z"}, {"author": "Dirk Trossen", "text": "@Chris \"The key thing I have a problem with is the current set of drafts I'm seeing where the compute resources are being shoved into the underlay networking layer.\" I am not entirely sure what this means. The decision of which compute resource is being utilized is being shoved into the underlay networking - is this what you mean?<br/>", "time": "2022-03-22T10:20:14Z"}, {"author": "Tony Li", "text": "@Chris Yup, one overlay plane per application. Resources/metric specific to the plane.<br/>", "time": "2022-03-22T10:20:21Z"}, {"author": "Tony Li", "text": "Then LB state is distributed so that you have session persistence across the front end.<br/>", "time": "2022-03-22T10:21:07Z"}, {"author": "Dirk Trossen", "text": "@Tony application or application category, i.e. could we have see the overlay as not necessarily service-specific but specific to categories of services?<br/>", "time": "2022-03-22T10:22:06Z"}, {"author": "Wim Henderickx", "text": "if you look today at 3GPP and URSP it solve this based on UPF selection. It uses both endpoint + application. Android has a prototype that supports this and was demonstrated in MWC.<br/>", "time": "2022-03-22T10:22:19Z"}, {"author": "Tony Li", "text": "Not a problem as long as they are willing to share policies.<br/>", "time": "2022-03-22T10:22:35Z"}, {"author": "Dirk Trossen", "text": "@Tony Agree!<br/>", "time": "2022-03-22T10:23:29Z"}, {"author": "Pete Resnick", "text": "More and more, this doesn't strike me as a routing problem; it's all service discovery that can be done in higher layers.<br/>", "time": "2022-03-22T10:25:17Z"}, {"author": "Christian Hopps", "text": "It still feels a bit off to me, and that the LB as part of the application itself is superior (part of the distributed application itself is to obtain and keep updating the \"best\" unicast location to use). <br/>", "time": "2022-03-22T10:25:29Z"}, {"author": "Joel Halpern", "text": "@Pete if not \"all\", very close thereto.<br/>", "time": "2022-03-22T10:25:36Z"}, {"author": "Richard Barnes", "text": "@Pete anycast does exist, and is used<br/>", "time": "2022-03-22T10:25:36Z"}, {"author": "Wim Henderickx", "text": "<a href=\"https://cloud.google.com/blog/topics/telecommunications/5g-network-slicing-with-google-android-enterprise-and-cloud\" rel=\"nofollow\">https://cloud.google.com/blog/topics/telecommunications/5g-network-slicing-with-google-android-enterprise-and-cloud</a><br/>", "time": "2022-03-22T10:25:45Z"}, {"author": "Aijun Wang", "text": "The network protocol is used to find the optimal destination. Why not use the more useful information to make the decision?<br/>", "time": "2022-03-22T10:25:58Z"}, {"author": "Dirk Kutscher", "text": "IMO, the point is that it can be done at different layers, and this is a proposal to employ the network/routing layer.<br/>", "time": "2022-03-22T10:26:01Z"}, {"author": "Pete Resnick", "text": "@rlb: It's not the anycast that strikes me weird; you could plausibly do SD over anycast. It's the construal of this as a problem for routers that I find odd.<br/>", "time": "2022-03-22T10:26:42Z"}, {"author": "Tony Li", "text": "The decision that you're making is not just an optimal path.<br/>", "time": "2022-03-22T10:26:47Z"}, {"author": "Zhenbin Li", "text": "@David Oran Yes. Similar as the B4.&nbsp;&nbsp;If the operators can learn both the application load and the network load, definitely they can achieve better traffic steering result. But B4 work maybe not standardized.<br/>", "time": "2022-03-22T10:26:57Z"}, {"author": "Tony Li", "text": "You want application information too, so you can't just make a decision at the network layer.<br/>", "time": "2022-03-22T10:27:10Z"}, {"author": "Pete Resnick", "text": "@Tony: +1<br/>", "time": "2022-03-22T10:27:14Z"}, {"author": "Richard Barnes", "text": "The thing i find odd here is the idea that you can only move your services around as fast as you can update the routing plane.&nbsp;&nbsp;which comes back to @Pete's point about service discovery<br/>", "time": "2022-03-22T10:27:38Z"}, {"author": "Richard Barnes", "text": "(waiting for convergence/distribution as opposed to just updating the SD server)<br/>", "time": "2022-03-22T10:28:08Z"}, {"author": "Cullen Jennings", "text": "@pete - yes - and in some (many) uses cases, if the applications can get a handful of possible services it could use, it can connect to *all* of them and test which is best this make a decision about what is optimal at an applications level.&nbsp;&nbsp;There is a big differences in requirements between \"my first packet needs to get to optimal places\" vs \"after sever round trip to multiple places, I get to a good place\"<br/>", "time": "2022-03-22T10:28:09Z"}, {"author": "Pete Resnick", "text": "@rlb: Yes, better put than I did.<br/>", "time": "2022-03-22T10:28:12Z"}, {"author": "Christian Hopps", "text": "if you want nice things to work like switching from one site to another based on current resource distribution, then the application needs to either be \"connection-less\" or has to be aware of the&nbsp;&nbsp;switching, and this is not different from being network aware I think.<br/>", "time": "2022-03-22T10:28:16Z"}, {"author": "Wim Henderickx", "text": "the dyncast proposal has to work behind or within UPF and in essence the d-router is a load-balancer as Shraddha presented<br/>", "time": "2022-03-22T10:28:35Z"}, {"author": "Zhenbin Li", "text": "@Tony the usecase is that the operator can hold both the network and application load. The network can learn the application load for better traffic steering. Yes, the controller should learn the application load info. This the work of dyncast.<br/>", "time": "2022-03-22T10:28:59Z"}, {"author": "Pete Resnick", "text": "@Cullen: Are there use cases they're looking at where the first packet has to get to the right place?<br/>", "time": "2022-03-22T10:29:29Z"}, {"author": "Cullen Jennings", "text": "I don't know<br/>", "time": "2022-03-22T10:30:06Z"}, {"author": "Rich Salz", "text": "yeah, VR and traffic seems to need the right answer first packet.<br/>", "time": "2022-03-22T10:30:10Z"}, {"author": "Christian Hopps", "text": "So what I keep thinking is that someone smart needs to write a framework for L7/applications that provides this network aware load balancing<br/>", "time": "2022-03-22T10:30:15Z"}, {"author": "Wim Henderickx", "text": "so another q is. We talk about initial selection, but what happens when the user moves? Do we want to address this? If so we also need to move application context.<br/>", "time": "2022-03-22T10:30:18Z"}, {"author": "Richard Barnes", "text": "@Rich quite the opposite.&nbsp;&nbsp;real-time stuff is an ideal position to adaptation<br/>", "time": "2022-03-22T10:30:35Z"}, {"author": "Tony Li", "text": "@Robin Yes, but once you've made that LB decision, it must be distributed across UPFs, so there's a lot more to be done.<br/>", "time": "2022-03-22T10:30:38Z"}, {"author": "David Oran", "text": "What's the assumed scale of a D-router? 10**6 sessions? 100*8? What's the assumed update rate? !Gb? 1Tb?<br/>", "time": "2022-03-22T10:30:46Z"}, {"author": "David Oran", "text": "Typical L4 LBs handle 10**6-10**7 sessions<br/>", "time": "2022-03-22T10:31:20Z"}, {"author": "Rich Salz", "text": "@rlb: ok; assume you know more than i do here.<br/>", "time": "2022-03-22T10:31:20Z"}, {"author": "Zhenbin Li", "text": "@Tony the solution and work items is open now.<br/>", "time": "2022-03-22T10:31:35Z"}, {"author": "Luigi Iannone", "text": "@Pete: the point&nbsp;&nbsp;is to let the network layer decide where is the \"right\" place, the decision is made by sharing knowledge about the different places<br/>", "time": "2022-03-22T10:31:35Z"}, {"author": "Tony Li", "text": "@Wim, my understanding is the state is replicated so that there is no change on a move.<br/>", "time": "2022-03-22T10:31:40Z"}, {"author": "Dirk Trossen", "text": "@Wim if your service instance selection does not change, users can move. But yes, if you want to assign new instance mid-session, there needs to be extra work, not at the routing level I would guess.<br/>", "time": "2022-03-22T10:31:42Z"}, {"author": "Richard Barnes", "text": "@Rich multimedia apps typically attempt multiple media servers before settling on the one that looks best, as @Cullen says.&nbsp;&nbsp;VR isn't really any different<br/>", "time": "2022-03-22T10:31:57Z"}, {"author": "Rich Salz", "text": "yeah, i know we do happy eyeballs racing all the time.<br/>", "time": "2022-03-22T10:32:17Z"}, {"author": "Richard Barnes", "text": "ah that's interesting, i was thinking that CDNs / TCP-based stuff might have more first-packet requirements.&nbsp;&nbsp;so it sounds neither case really does.<br/>", "time": "2022-03-22T10:33:00Z"}, {"author": "Wim Henderickx", "text": "@Toni, agreed but this is an implicit assumption and need to be aligned with the app.<br/>", "time": "2022-03-22T10:33:02Z"}, {"author": "Daniel Bernier", "text": "so client-apps are pretty good right now to know and adapt best edge server based on app metrics. However, to adjust their UPF anchoring is not trivial<br/>", "time": "2022-03-22T10:33:23Z"}, {"author": "Wim Henderickx", "text": "@Dirk, indeed my point is you cannot do this in isolation at the routing level. The application part is very critical<br/>", "time": "2022-03-22T10:34:00Z"}, {"author": "Christian Hopps", "text": "@joel +1<br/>", "time": "2022-03-22T10:34:16Z"}, {"author": "Rich Salz", "text": "@rlb: no, we do both.&nbsp;&nbsp;we want to get the client to the right edge server immediately and then we race to find the best way (or even ip4/ip6) to get the client to the right server<br/>", "time": "2022-03-22T10:34:18Z"}, {"author": "Mohamed Boucadair", "text": "all good and fair comments from Joel.<br/>", "time": "2022-03-22T10:34:32Z"}, {"author": "Dirk Trossen", "text": "@Wim I do agree, hard to disagree. I don't think the proposal here is that ALL those aspects are solved at the routing level though<br/>", "time": "2022-03-22T10:34:45Z"}, {"author": "Wim Henderickx", "text": "@daniel, if you look at the URSP thing in 3GPP the UPF selection is becoming much more dynamic and in my view addresses this. No matter what we do here if the scope is mobile, the UPF anchor is critical.<br/>", "time": "2022-03-22T10:36:16Z"}, {"author": "Wim Henderickx", "text": "Btw URSP is not the UPF selection but also influences radio resources and schedulers, etc. So it is even bigger than the edge selection.<br/>", "time": "2022-03-22T10:37:51Z"}, {"author": "Wim Henderickx", "text": "sorry meant not only UPF selection<br/>", "time": "2022-03-22T10:38:49Z"}, {"author": "Adrian Farrel", "text": "Erik just made some really key points. There is a very big difference between micro-computations needed in pseudo-realtime (such as in automotive?) and larger computations<br/>", "time": "2022-03-22T10:42:00Z"}, {"author": "Srihari Sangli", "text": "+1<br/>", "time": "2022-03-22T10:42:21Z"}, {"author": "Srihari Sangli", "text": "Clarifications on the computing resource, its requirements and characteristics would be helpful<br/>", "time": "2022-03-22T10:43:14Z"}, {"author": "Dirk Trossen", "text": "@Adrian +1 but I also think we need to discuss more the basis for decision, i.e., the metrics. Even the term LB is putting too much emphasis on the idea of regular load updates. Is this the (only) approach we are thinking about?<br/>", "time": "2022-03-22T10:43:48Z"}, {"author": "Lars Eggert", "text": "i think lb is really the wrong mental model here. the point of lb is to *balance* a large inbound request load over a tightly-controlled and regularized network to a set of identical servers (and at minimum resource cost.) the uses cases here seem to be much more about bespoke \"optimal\" placement of individual requests.<br/>", "time": "2022-03-22T10:47:09Z"}, {"author": "Tony Li", "text": "@Lars How is that not LB?<br/>", "time": "2022-03-22T10:47:39Z"}, {"author": "Dirk Trossen", "text": "@Tony load may not be the only metric maybe?<br/>", "time": "2022-03-22T10:48:19Z"}, {"author": "Lars Eggert", "text": "in lb, you don't usually care which server instance (and over which path) you land on. that seems to matter a hole lot here?<br/>", "time": "2022-03-22T10:48:32Z"}, {"author": "Luigi Iannone", "text": "Yes Lars, that is the difference in a nutshell<br/>", "time": "2022-03-22T10:49:07Z"}, {"author": "Tony Li", "text": "Granted, there's more than load in the decision. The point is that you're making a decision on the front end.<br/>", "time": "2022-03-22T10:49:09Z"}, {"author": "Dirk Trossen", "text": "in edge computing, HW capabilities, for instance, may be highly important. It goes along Lars' \"set of identical servers' point.<br/>", "time": "2022-03-22T10:49:18Z"}, {"author": "Tony Li", "text": "And it's not just a routing decision.<br/>", "time": "2022-03-22T10:49:26Z"}, {"author": "Pete Resnick", "text": "I think to the \"questions\": It sounds like there are some important use cases, but it sounds like we need to spend more time separating them out in order to answer the second question: There probably are existing and sufficient solutions for some of them.<br/>", "time": "2022-03-22T10:49:26Z"}, {"author": "Luigi Iannone", "text": "@Tony: \"informed\" decision in the front end...<br/>", "time": "2022-03-22T10:49:44Z"}, {"author": "Rich Salz", "text": "it would be good to have a different term for this use-case than \"load balancer\"&nbsp;&nbsp;more like \"load director\"<br/>", "time": "2022-03-22T10:49:53Z"}, {"author": "Ketan Talaulikar", "text": "@Dirk how about we start simple and with just one metric \"load\". Can that be specified and fleshed out first? Then we know what is possible and what makes sense to tackle in the routing protocols. We can get to combination of metrics as a further step. Makes sense?<br/>", "time": "2022-03-22T10:50:06Z"}, {"author": "Dirk Kutscher", "text": "It's effectively LB, but it's doing more than ECMP....<br/>", "time": "2022-03-22T10:50:07Z"}, {"author": "Daniel Bernier", "text": "@Wim thanks, confirming my point, a DNS/LB feature happening AFTER the UPF selection would be already *influenced*<br/>", "time": "2022-03-22T10:50:18Z"}, {"author": "Tony Li", "text": "Exactly<br/>", "time": "2022-03-22T10:50:21Z"}, {"author": "Jeff Tantsura", "text": "@tony - aren't you waiting for an imminent proposal to flood it in IGP ;-)<br/>", "time": "2022-03-22T10:50:49Z"}, {"author": "Peng Liu", "text": "The use case has two parts to get two but seen as one conclusion, steering traffic considering both network and computing resource status.<br/>", "time": "2022-03-22T10:51:32Z"}, {"author": "Ketan Talaulikar", "text": "@jeff ... i think we already got one?<br/>", "time": "2022-03-22T10:51:33Z"}, {"author": "Tony Li", "text": "Yes, then I roll out my dump truck. :)<br/>", "time": "2022-03-22T10:51:34Z"}, {"author": "Dirk Trossen", "text": "@Ketan fair point and something that sounds reasonable, indeed.<br/>", "time": "2022-03-22T10:51:52Z"}, {"author": "Julien Maisonneuve", "text": "On compute metrics collection DMTF has a head start.<br/>", "time": "2022-03-22T10:52:08Z"}, {"author": "Jeff Tantsura", "text": "yes, a composite/normalized metric would be very helpful indeed<br/>", "time": "2022-03-22T10:52:21Z"}, {"author": "Luigi Iannone", "text": "I think that the routing protocol is just&nbsp;&nbsp;away to distribute the knowledge that the LB++ (in alack of a more generic name) will use to do informed decision<br/>", "time": "2022-03-22T10:53:11Z"}, {"author": "Luigi Iannone", "text": "Is not something that necessarily will impact each and every router in&nbsp;&nbsp;the network<br/>", "time": "2022-03-22T10:53:36Z"}, {"author": "Pete Resnick", "text": "Loops?<br/>", "time": "2022-03-22T10:53:51Z"}, {"author": "Tony Li", "text": "If you start shoving other metrics into the routing protocols, then you are very much impacting each and every router.<br/>", "time": "2022-03-22T10:54:10Z"}, {"author": "Christian Hopps", "text": "Luigi so that's the dump truck thing.. i.e., don't turn OSPF or IS-IS into a dump truck for distributing state.<br/>", "time": "2022-03-22T10:54:12Z"}, {"author": "Jeff Tantsura", "text": "@pete - tunnels solve this one<br/>", "time": "2022-03-22T10:54:23Z"}, {"author": "Jeff Tantsura", "text": "@chris - sure, we have got BGP for that ;-)<br/>", "time": "2022-03-22T10:54:44Z"}, {"author": "Joel Halpern", "text": "@Luigi a) If the proposal said it would encaps, that might be true.&nbsp;&nbsp;b) burdening all the routers in teh domain with propagating information needed by ingress edges seems an odd way to approach the problem.<br/>", "time": "2022-03-22T10:54:45Z"}, {"author": "Luigi Iannone", "text": "I do not think that loop problem will be worse (but metrics need some thoughts)<br/>", "time": "2022-03-22T10:54:57Z"}, {"author": "David Oran", "text": "Don't we also have to consider the question of \"where do i instantiate the computation based on where the network can delivery the data\"? This seems to assume the computations are ready to run and just telling the network how to delivery the data. That's the essence of \"joint optimization\", which can't be done in L3 alone since L3 can't cause computational resources to appear on demand.<br/>", "time": "2022-03-22T10:55:21Z"}, {"author": "Luigi Iannone", "text": "@ Joel: Yes to both points<br/>", "time": "2022-03-22T10:55:54Z"}, {"author": "Pete Resnick", "text": "I'll chat offline. I'm having a real problem getting myself to see this as routing. The existense of \"loops\" doesn't make any sense to me.<br/>", "time": "2022-03-22T10:56:05Z"}, {"author": "Shraddha Hegde", "text": "whether to bring compute awareness into routing layer or bring network awareness into LB layer is something that needs to be debated<br/>", "time": "2022-03-22T10:56:11Z"}, {"author": "Lars Eggert", "text": "@daveo yes. this problem is significantly harder than lb<br/>", "time": "2022-03-22T10:56:12Z"}, {"author": "Luigi Iannone", "text": "@ Chris: is not about dumping anything in the routing layer ... I think this is part of the work to be done, what to put there and how to use it.<br/>", "time": "2022-03-22T10:56:38Z"}, {"author": "Zongpeng Du", "text": "agree<br/>", "time": "2022-03-22T10:56:38Z"}, {"author": "Tony Li", "text": "@Shraddha Only if you think that adding more data to routing is a sane thing to do.<br/>", "time": "2022-03-22T10:56:52Z"}, {"author": "Jeff Tantsura", "text": "+1 tony<br/>", "time": "2022-03-22T10:57:10Z"}, {"author": "Joel Halpern", "text": "Between existing network exposure work, and existing data center exposure work, it seems that the placement problem is an application space problem currently ripe for explorationa nd differentiaation.<br/>", "time": "2022-03-22T10:57:26Z"}, {"author": "David Oran", "text": "@Lars\" this is the stuff i was referring to when I brought up Saphire and Ray.<br/>", "time": "2022-03-22T10:57:27Z"}, {"author": "Dirk Kutscher", "text": "IMO, this work needs to be informed about how relevant distributed computing systems work, i.e., systems like Ray<br/>", "time": "2022-03-22T10:57:39Z"}, {"author": "Luigi Iannone", "text": "@Tony: Yes, if you put information in the routing layer every router is impacted. The more correct statement would be \"not all of the router use the information\" which may lead to too much overhead...<br/>", "time": "2022-03-22T10:57:44Z"}, {"author": "Jeff Tantsura", "text": "@Luigi -&nbsp;&nbsp;that is why we have overlays<br/>", "time": "2022-03-22T10:58:35Z"}, {"author": "Christian Hopps", "text": "The chat transcript is archived, yes?<br/>", "time": "2022-03-22T10:58:39Z"}, {"author": "Pete Resnick", "text": "Yes.<br/>", "time": "2022-03-22T10:58:44Z"}, {"author": "Christian Hopps", "text": "cool<br/>", "time": "2022-03-22T10:58:58Z"}, {"author": "cabo", "text": "<a href=\"https://jabber.ietf.org/jabber/logs/can/2022-03-22.html\" rel=\"nofollow\">https://jabber.ietf.org/jabber/logs/can/2022-03-22.html</a> <br/>", "time": "2022-03-22T10:59:15Z"}, {"author": "Zongpeng Du", "text": "The computing information can be processed just like the OAM information in the network<br/>", "time": "2022-03-22T10:59:40Z"}, {"author": "Luigi Iannone", "text": "@Jeff: right. That is one way to do it.<br/>", "time": "2022-03-22T10:59:56Z"}, {"author": "Wim Henderickx", "text": "does IETF has a definition or has there been work done on a load-balancer?<br/>", "time": "2022-03-22T11:00:55Z"}, {"author": "Zongpeng Du", "text": "only the PE node need to process them<br/>", "time": "2022-03-22T11:00:59Z"}, {"author": "Pete Resnick", "text": "Good summary John.<br/>", "time": "2022-03-22T11:01:16Z"}, {"author": "Tony Li", "text": "Pointer to mailing list please?<br/>", "time": "2022-03-22T11:01:21Z"}, {"author": "Jeff Tantsura", "text": "@Luigi - only the end points (head-end/tail-end) are concerned with the state related, it has nothing to do with the rest of the network<br/>", "time": "2022-03-22T11:01:23Z"}]