[{"author": "Tobia Castaldi", "text": "

test

", "time": "2022-11-07T15:44:47Z"}, {"author": "Anthony Somerset", "text": "

Tobia Castaldi said:

\n
\n

test

\n
\n

recieved

", "time": "2022-11-07T15:46:33Z"}, {"author": "Ketan Talaulikar", "text": "

Is it fair to say that this is only about routing for anycast destinations?

", "time": "2022-11-07T15:46:55Z"}, {"author": "Joel Halpern", "text": "

It is about traffic with any cast destinations. IT should be about edge initiated tunnels, not routing of anycast packets in the network.

", "time": "2022-11-07T15:48:18Z"}, {"author": "Ketan Talaulikar", "text": "

OK. So all about anycast destinations only ... right? Want to make sure not missing anything else ...

", "time": "2022-11-07T15:49:39Z"}, {"author": "Zongpeng Du", "text": "

To make it reasonable and efficient, many details may be considered here

", "time": "2022-11-07T15:50:14Z"}, {"author": "Joel Halpern", "text": "

When we get to the charter, we need to seal with the existence of two problems, one about edge selection a d one about injecting information into routing. The former makes sense. The later us a bad idea that I believe the previous bof rejected.

", "time": "2022-11-07T15:57:00Z"}, {"author": "Tony Li", "text": "

It seems to me that some solutions may make a decision and convert from anycast to unicast.

", "time": "2022-11-07T15:58:25Z"}, {"author": "Ketan Talaulikar", "text": "

@Tony best path decision?

", "time": "2022-11-07T16:00:04Z"}, {"author": "Tony Li", "text": "

Exactly. Use anycase to get to the decision point and then convert.

", "time": "2022-11-07T16:00:34Z"}, {"author": "Joel Halpern", "text": "

@Tony Li I expect it is encapsulate rather than convert, but yes. The edge selects the oath and then we get unicast routing.

", "time": "2022-11-07T16:01:04Z"}, {"author": "Andrew Alston", "text": "

(Speaking with no hats) So I\u2019m confused - they said - 38 issues at last bof - all answered - none closed - they need to be dealt with in a wg. Yet - it was those 38 issues that seemed to stymie the creation of a wg in the first place - so what changed?

", "time": "2022-11-07T16:01:14Z"}, {"author": "Darren Dukes", "text": "

From a use case POV: is it correct that the use case is a host consuming an application service that happens to be deployed at its closest edge, and the network decides to route that service request to a different service instance at a different edge site based on network and application performance?

", "time": "2022-11-07T16:01:26Z"}, {"author": "Tony Li", "text": "

@Joel Halpern That's just conversion with more overhead.

", "time": "2022-11-07T16:02:02Z"}, {"author": "Ketan Talaulikar", "text": "

@Tony ... thanks. That is what I was thinking but wanted to see if I was not missing the basic. I didn't get that clarity from the use cases and so will wait for the Gap

", "time": "2022-11-07T16:02:03Z"}, {"author": "Joel Halpern", "text": "

A subset of proponents want the whole network looking at and deciding about the anycast destination address.

", "time": "2022-11-07T16:04:53Z"}, {"author": "Darren Dukes", "text": "

@Tony Li and @Ketan Talaulikar is the anycast idea required? if I push my cloud service model to the edge, am I using an anycast address?

", "time": "2022-11-07T16:04:59Z"}, {"author": "Andrew Alston", "text": "

Why can this not be done using sr label stack to steer to correct point with conversation to controller from the applications that are aware of this and want to use it?

", "time": "2022-11-07T16:05:16Z"}, {"author": "Andrew Alston", "text": "

Though - that\u2019s just one way to do it of course - if you accept tunneling there are many ways to do this

", "time": "2022-11-07T16:05:48Z"}, {"author": "Ketan Talaulikar", "text": "

@Darren no but that is not done by routing layer. Here we seem to want to solve that problem in the routing layer.

", "time": "2022-11-07T16:06:14Z"}, {"author": "Tony Li", "text": "

@Darren Dukes AFAICT, no. A unicast service address would suffice. It's simply being used as a service selector.

", "time": "2022-11-07T16:06:25Z"}, {"author": "Anthony Somerset", "text": "

i was about to suggest similar - load balancers can perform pretty high end logic to make routing decisions and could easily presumably fire off API calls to some controller to influence the network level

", "time": "2022-11-07T16:06:29Z"}, {"author": "John Scudder", "text": "

According to my recollection, @Joel Halpern is right that an outcome of the previous BOF was that this is restricted to edge selection, and that injection into the underlay is out of scope.

", "time": "2022-11-07T16:06:29Z"}, {"author": "Darren Dukes", "text": "

@Andrew Alston I'm not sure... Im interested to see what the Gap analysis says if I'm understanding the use cases (that's a big if ;)

", "time": "2022-11-07T16:06:33Z"}, {"author": "Boris Khasanov", "text": "

@Andrew +1

", "time": "2022-11-07T16:06:58Z"}, {"author": "Zongpeng Du", "text": "

@Tony Li In my understanding, the convert can also happen in the peer, instead of on the ingress router. The main point is that the decision is made on the ingress router

", "time": "2022-11-07T16:07:53Z"}, {"author": "Andrew Alston", "text": "

dynamic tunneling to push to specific end points from an application layer using sr mpls label stacks is something we have done internally for various reasons - and it works. And any application that would need to do this type of stuff would have to be talking to something to give it network info any way

", "time": "2022-11-07T16:08:06Z"}, {"author": "Peng Liu", "text": "

CAN won't injection into the underlay, it is about the ingress or edge

", "time": "2022-11-07T16:08:45Z"}, {"author": "Tony Li", "text": "

Please refresh my memory. From our previous discussions, it looked like load balancing was the likely result. I thought we redirected them to the load balancing working group.

", "time": "2022-11-07T16:09:43Z"}, {"author": "Ketan Talaulikar", "text": "

so if this is just path selection at ingress PE then it is only about anycast ... having many paths and picking the \"best\" path amongst them based on \"foo\" metric and then finally steering the packets to that egress PE via some TE mechanism.

", "time": "2022-11-07T16:09:58Z"}, {"author": "Andrew Alston", "text": "

Peng - so - either something is telling the network about the applications/nodes - or - the nodes are getting that information themselves and then telling the network how to steer to the end points - surely the end result is the same thing - but one can be done with existing tech

", "time": "2022-11-07T16:10:11Z"}, {"author": "Ketan Talaulikar", "text": "

Am I missing something

", "time": "2022-11-07T16:10:18Z"}, {"author": "Jim Uttaro", "text": "

Ketan +1

", "time": "2022-11-07T16:10:22Z"}, {"author": "John Scudder", "text": "

@Ketan Talaulikar I don\u2019t think it\u2019s about picking on the \u201cfoo\u201d metric. They haven\u2019t used the term \u201cmulti-objective optimization\u201d but AFAICT that\u2019s exactly what\u2019s being contemplated.

", "time": "2022-11-07T16:11:03Z"}, {"author": "Yuexia Fu", "text": "

Common to solutions such as DNS, ALTO, or Layer 4 & Layer 7 load balancers is the exposure and usage of network conditions for decision making. None of the existing solutions integrate the computing resource conditions with the network conditions for deciding the optimal paths.

", "time": "2022-11-07T16:11:25Z"}, {"author": "Ketan Talaulikar", "text": "

@John I attempted to mind read there :-)

", "time": "2022-11-07T16:11:31Z"}, {"author": "Cheng Li", "text": "

it would be instance selection, not path selection, after selecting a instance, the path can be seleccted by the existing solutions I guess.

", "time": "2022-11-07T16:11:49Z"}, {"author": "Tony Li", "text": "

I don't see how multiple metrics changes the architecture.

", "time": "2022-11-07T16:11:59Z"}, {"author": "Cheng Li", "text": "

But the key point is, using the computing-related metric to impart the routing decisions.

", "time": "2022-11-07T16:12:25Z"}, {"author": "Ketan Talaulikar", "text": "

@Cheng how is instance defined? Is it about picking an IP destination?

", "time": "2022-11-07T16:12:34Z"}, {"author": "John Scudder", "text": "

@Tony Li depends on your assumptions, I was specifically responding to Ketan\u2019s characterization.

", "time": "2022-11-07T16:12:56Z"}, {"author": "Jim Uttaro", "text": "

How often does the computing-related metric get updated to ensure the intended outcome?

", "time": "2022-11-07T16:13:08Z"}, {"author": "Darren Dukes", "text": "

Load balancers are not a single point of failure, AFAIK. There are HA patterns for them...

", "time": "2022-11-07T16:13:20Z"}, {"author": "Stewart Bryant", "text": "

If this is instance selection why isn't this an application overlay?

", "time": "2022-11-07T16:13:34Z"}, {"author": "Ketan Talaulikar", "text": "

@Stewart that would have been my next Q too ...

", "time": "2022-11-07T16:13:56Z"}, {"author": "Boris Khasanov", "text": "

@Jim, IMO, it depends on a service which it belongs.

", "time": "2022-11-07T16:13:58Z"}, {"author": "Robert Raszuk", "text": "

@stewart To me this is 100% application overlay

", "time": "2022-11-07T16:14:04Z"}, {"author": "Jim Uttaro", "text": "

Agreed

", "time": "2022-11-07T16:14:07Z"}, {"author": "Cheng Li", "text": "

if it is a unicast, that is an IP address, if it is a anycast, it may be a path, or another unicast address of a specific instance. But anyway, this is open for discussion in the next stage, not today's meeting. In this BOF, we only discuss the use case and gap analysis, no solution will be discussed.

", "time": "2022-11-07T16:14:10Z"}, {"author": "Anthony Somerset", "text": "

Darren Dukes said:

\n
\n

Load balancers are not a single point of failure, AFAIK. There are HA patterns for them...

\n
\n

+1 to this - Anycast + LB + Backend routing logic

", "time": "2022-11-07T16:14:12Z"}, {"author": "Joel Halpern", "text": "

@Peng Liu will the charter proposal be clarified to make that clear?

", "time": "2022-11-07T16:14:37Z"}, {"author": "Zongpeng Du", "text": "

It depends on the need of the service about the frequency

", "time": "2022-11-07T16:14:37Z"}, {"author": "Daniel Bernier", "text": "

the question is about having a client be able to ask for the right available resource ... how this resource is then reached (any cast, SR labels, LB) is secondary ... and can vary

", "time": "2022-11-07T16:14:48Z"}, {"author": "Yuexia Fu", "text": "

multiple metrics will change the routing decisions, both considering the computing metric and routing metric

", "time": "2022-11-07T16:15:03Z"}, {"author": "Andrew Alston", "text": "

So my big problem with this - telling the network about compute resource etc - means that the network itself has to be under control of the party doing this - an sp ain\u2019t gonna let customers send stuff like this into the network - and if you do this via the alternative - where the node gets the info - and then tells the network how to steer it - that is far more palatable from my view as an sp (and safer)

", "time": "2022-11-07T16:15:06Z"}, {"author": "Stewart Bryant", "text": "

It does not need anything fancy like anycast except perhaps to the instance section server, but after that it can simple unicast

", "time": "2022-11-07T16:15:15Z"}, {"author": "Daniel Bernier", "text": "

so having the developer deploy its application at the right compute location is a case for proper cloud resource scheduling

", "time": "2022-11-07T16:15:32Z"}, {"author": "Ketan Talaulikar", "text": "

instance selection server = LB ? ;-)

", "time": "2022-11-07T16:15:39Z"}, {"author": "Tony Li", "text": "

Don't tell the entire network, just the LB box.

", "time": "2022-11-07T16:15:41Z"}, {"author": "Gyan Mishra", "text": "

@ketan I believe the goal is how to provide the compute awareness to the network so the network is more compute aware to make a better decision in the route selection process . So a more intelligent metric would injected into the network so the network becomes more intelligent for optimal routing decisions.

", "time": "2022-11-07T16:16:24Z"}, {"author": "Andrew Alston", "text": "

tony that dictates lbs but I get the impression that ain\u2019t what is wanted - if it is - you don\u2019t need to do this at a network layer and it ain\u2019t routing

", "time": "2022-11-07T16:16:29Z"}, {"author": "Jim Uttaro", "text": "

@Gyan What is that all encompassing metric? I thought it was specific to a given application i.e availability, jitter, latency etc...

", "time": "2022-11-07T16:17:14Z"}, {"author": "Robert Raszuk", "text": "

It almost sounds like some folks would like to see a distributed LB present in the transit network. Don't think this is good idea.

", "time": "2022-11-07T16:17:16Z"}, {"author": "Zongpeng Du", "text": "

It is about do the LB in the network node which is near to the users

", "time": "2022-11-07T16:17:31Z"}, {"author": "Daniel Bernier", "text": "

the question is around HOW can the client ask \"someone\" for a service that is available with the right compute/processing capacity ... then he can worry about how to get there

", "time": "2022-11-07T16:17:45Z"}, {"author": "Andrew Alston", "text": "

so either - you tell the network - which is a problem in my view - or the nodes apply things to steer when they get the info themselves (in which case we have tech to do this) - or you use lbs in which case this ain\u2019t really routing per say

", "time": "2022-11-07T16:18:01Z"}, {"author": "Cheng Li", "text": "

well, it is hard to explain to much in the short time. I will recommend the pople to read the draft before asking, or read the issues in the github. The questions are quite similar. So hope not to repeat the discussion in the previous BOF :(

", "time": "2022-11-07T16:18:06Z"}, {"author": "Tony Li", "text": "

We seem to have a lot of assumed solutions without thinking about the real requirements and architecture.

", "time": "2022-11-07T16:18:11Z"}, {"author": "Ketan Talaulikar", "text": "

@Dan is that for routing layer to answer?

", "time": "2022-11-07T16:18:20Z"}, {"author": "Stewart Bryant", "text": "

The compute availability needs to be a private matter else there are security and commercial issues

", "time": "2022-11-07T16:18:23Z"}, {"author": "Peng Liu", "text": "

Not underlay, of course, CAN won't impact every router, if the charter is not clear about that, we can refine it.

", "time": "2022-11-07T16:19:52Z"}, {"author": "Tony Li", "text": "

@Tom Hill We run OSPF on handsets! :-)

", "time": "2022-11-07T16:20:20Z"}, {"author": "Gyan Mishra", "text": "

@Jim - the all encompassing metric would be more compute aware - based on compute load resources details as well as compute requirements of delay, jitter, availability - so a compound intelligent metric for routing optimization

", "time": "2022-11-07T16:20:27Z"}, {"author": "Daniel Bernier", "text": "

@ketan I am biassed against. There are existing mechanisms to do such a thing

", "time": "2022-11-07T16:20:40Z"}, {"author": "Anthony Somerset", "text": "

@Tony Li are you sure you didn't mean RIP?

", "time": "2022-11-07T16:20:47Z"}, {"author": "Andrew Alston", "text": "

Ospf? Please - use isis and add another afi

", "time": "2022-11-07T16:20:58Z"}, {"author": "Peng Liu", "text": "

How to response to the specific message...I mean @..

", "time": "2022-11-07T16:21:42Z"}, {"author": "Daniel Bernier", "text": "

look at BBF ATSSS and or any cloud directory service ... no DNS, no LB, but proper traffic steering

", "time": "2022-11-07T16:21:56Z"}, {"author": "Zongpeng Du", "text": "

It is on the ingress node, not on all the transit network. @Robert Raszuk
\nIt almost sounds like some folks would like to see a distributed LB present in the transit network. Don't think this is good idea.

", "time": "2022-11-07T16:22:04Z"}, {"author": "Anthony Somerset", "text": "

@Peng Liu type @ then start typing the users name it will give the option to complete - you must be using Zulip not meetecho though

", "time": "2022-11-07T16:22:20Z"}, {"author": "Richard Barnes", "text": "

just to be clear -- my name being on this slide DOES NOT mean i support this work!

", "time": "2022-11-07T16:22:27Z"}, {"author": "Richard Barnes", "text": "

i assume that applies to a bunch of other folks as well

", "time": "2022-11-07T16:22:39Z"}, {"author": "Tony Li", "text": "

Indeed

", "time": "2022-11-07T16:22:52Z"}, {"author": "Ketan Talaulikar", "text": "

@Dan +1 for traffic steering

", "time": "2022-11-07T16:23:05Z"}, {"author": "Joel Halpern", "text": "

@Richard Barnes agreed.

", "time": "2022-11-07T16:23:28Z"}, {"author": "Robert Raszuk", "text": "

@Zongpeng Du define ingresss node. Is this my CE ? My home gw ? my provider's PE ?

", "time": "2022-11-07T16:23:39Z"}, {"author": "Andrew Alston", "text": "

I would suggest someone who is on that slide - make that clear at the microphone for those not reading this because it\u2019s misleading

", "time": "2022-11-07T16:23:59Z"}, {"author": "Zongpeng Du", "text": "

my provider's PE

", "time": "2022-11-07T16:24:22Z"}, {"author": "Peng Liu", "text": "

it use '/Comments' not all support, we divide them, there is the blank

", "time": "2022-11-07T16:24:48Z"}, {"author": "Anthony Somerset", "text": "

@Zhaohui Zhang can you relay @Richard Barnes comment to the room

", "time": "2022-11-07T16:25:08Z"}, {"author": "Ketan Talaulikar", "text": "

The list on that slide seems to have gotten truncated for the 2nd set of people?

", "time": "2022-11-07T16:25:54Z"}, {"author": "Peng Liu", "text": "

We list the name of all the people give the comments in the pre BoF in IETF113, not means all to support. Anyway, we thanks for that. 2nd set are the people who gave comments.

", "time": "2022-11-07T16:26:37Z"}, {"author": "Peng Liu", "text": "

there is a blank

", "time": "2022-11-07T16:26:59Z"}, {"author": "Tony Li", "text": "

Subheaders would be a good clarification

", "time": "2022-11-07T16:27:22Z"}, {"author": "Andrew Alston", "text": "

I\u2019m really struggling to wrap my head around this - because if an application makes a decision and then stacks information to dictate the routing - that should give same performance. If they use LBs it\u2019s another way - if they require the network to have info to make decisions - that almost entirely eliminates any ability as an SP to productive this because I don\u2019t see an SP wanting to know about their clients compute resources

", "time": "2022-11-07T16:32:07Z"}, {"author": "Daniel Bernier", "text": "

@Dirk Trossen when is the side meeting ? .... forget it I found the info

", "time": "2022-11-07T16:32:28Z"}, {"author": "Anthony Somerset", "text": "

There are potential legal and privacy implications to consider here - especially if content providers wish to chase down copyright abuse etc - could leave Service Providers open to major littigation risks

", "time": "2022-11-07T16:33:36Z"}, {"author": "Hang Shi", "text": "

I do not understand, why legal risk?

", "time": "2022-11-07T16:35:29Z"}, {"author": "Boris Khasanov", "text": "

@Andrew, some similarities with RSVP, isn't it?

", "time": "2022-11-07T16:35:34Z"}, {"author": "Cheng Li", "text": "

NOTE: this BOF only discuss the use case and gap analysis, so the solution related text is removed as suggestions from people have interested in the work and responsible ADs.

", "time": "2022-11-07T16:37:14Z"}, {"author": "Andrew Alston", "text": "

@Boris Khasanov in some ways yes - but there are a bunch of safer / better ways to do this imho - some of which we implemented in house that rely on the application getting the information and then dictating how it labels it\u2019s traffic going into the network so it can be steered - that doesn\u2019t mess with the underlay network - and in my view is way way safer

", "time": "2022-11-07T16:37:52Z"}, {"author": "Anthony Somerset", "text": "

Hang Shi said:

\n
\n

I do not understand, why legal risk?

\n
\n

Content provider A provides streaming Service B

\n

Customer C illegaly gets Streaming Service B via some Dodgy content provider D

\n

Content Provider D provides CAN based meta data to network to optimise performance

\n

Content provider A sues Service Provider to block or stop or provide information on the illegal operations

\n

Service Provider doesn't have usefull ability to filter/block the illegal traffic - they only care about getting packets from A end to B end

", "time": "2022-11-07T16:38:27Z"}, {"author": "Zongpeng Du", "text": "

It is about the ingress to know about the server status, not the client.

", "time": "2022-11-07T16:38:35Z"}, {"author": "Zongpeng Du", "text": "

In my understanding, the ingress routers in CAN need to obtain some information, and then make a routing policy or update an existing policy accordingly. The routing mechanism underlayer should be the same as before.

", "time": "2022-11-07T16:39:12Z"}, {"author": "Andrew Alston", "text": "

heh - and if the ingress router is a service provider would - the SP doesn\u2019t want to know about it\u2019s clients server status in that matter

", "time": "2022-11-07T16:40:14Z"}, {"author": "Stewart Bryant", "text": "

Does this scale?

", "time": "2022-11-07T16:42:13Z"}, {"author": "Tony Li", "text": "

@Stewart Bryant If done right, it doesn't need to.

", "time": "2022-11-07T16:42:36Z"}, {"author": "Andrew Alston", "text": "

Stewart actually probably far better - a controller can talk to the nodes and exchange info - versus - a controller feeding the network with constant and highly variable/volatile info with is having to change things all the time?

", "time": "2022-11-07T16:43:23Z"}, {"author": "Antoine Fressancourt", "text": "

I don\u2019t really get why people object the group from investigating network layer mechanisms to do CAN. If you think that upper layers solve the issue, that\u2019s perfect. If you don\u2019t want to support CAN in your network that\u2019s fine, but why people willing to explore the problem space be prevented to do so ?

", "time": "2022-11-07T16:44:31Z"}, {"author": "Tony Li", "text": "

Two words: layer violation

", "time": "2022-11-07T16:44:59Z"}, {"author": "Martin Vigoureux", "text": "

Have we agreed that this problem needs to be solved by routing based solutions?

", "time": "2022-11-07T16:45:23Z"}, {"author": "Tony Li", "text": "

No, we have not.

", "time": "2022-11-07T16:45:36Z"}, {"author": "Susan Hares", "text": "

Does a compute resources create a policy that simply color a route (like a community) so you know how to evaluate it for a prefix?

", "time": "2022-11-07T16:45:54Z"}, {"author": "Martin Vigoureux", "text": "

So why are we discussing a routing centric charter?

", "time": "2022-11-07T16:46:21Z"}, {"author": "Stewart Bryant", "text": "

I agree with Tony - the proponents have not demonstrated that this is a routing problem and that this is the best use of IETF resources

", "time": "2022-11-07T16:46:28Z"}, {"author": "Zongpeng Du", "text": "

If there is enough motivations, cross layer design can also be considered.

", "time": "2022-11-07T16:46:30Z"}, {"author": "Tony Li", "text": "

My point exactly.

", "time": "2022-11-07T16:46:31Z"}, {"author": "Andrew Alston", "text": "

Martin +1

", "time": "2022-11-07T16:46:45Z"}, {"author": "Tony Li", "text": "

In fact, we haven't shown that this is anything other than an extension to LB protocols. So why not toss this into the LB WG?

", "time": "2022-11-07T16:47:15Z"}, {"author": "Antoine Fressancourt", "text": "

It would sure be a first

", "time": "2022-11-07T16:48:17Z"}, {"author": "Antoine Fressancourt", "text": "

(Speaking about layer violation from Tony)

", "time": "2022-11-07T16:49:02Z"}, {"author": "Tommaso Pecorella", "text": "

A suggestion for the charter. The acronym for Fault, Configuration , \u2026 should be FCAPS (in the slides the \u201cS\u201d is missing)

", "time": "2022-11-07T16:49:51Z"}, {"author": "Ryo Yanagida", "text": "

That does not mean layer violation should be encouraged\u2026. Surely.

", "time": "2022-11-07T16:50:02Z"}, {"author": "Daniel Bernier", "text": "

@antoine I am all for looking and investigating different data for route/path calculation as an evolution. But to me for the current problem statement, it is mostly around client request towards the proper resource ... I might need a beer to be convinced otherwise ;-)

", "time": "2022-11-07T16:50:59Z"}, {"author": "Anthony Somerset", "text": "

@Daniel Bernier only 1 beer?

", "time": "2022-11-07T16:51:51Z"}, {"author": "Martin Vigoureux", "text": "

From the slides shown today I'm under the impression that the gap analysis rules out existing solutions rather than identifies what's missing.

", "time": "2022-11-07T16:52:05Z"}, {"author": "Anthony Somerset", "text": "

how about a brewery?

", "time": "2022-11-07T16:52:08Z"}, {"author": "Zongpeng Du", "text": "

Traditional LB does not happen on the ingress nodes, CAN focuses on a more efficient LB solution.

", "time": "2022-11-07T16:52:31Z"}, {"author": "Tony Li", "text": "

@Martin Vigoureux When in fact, the answer is probably just extending an existing solution.

", "time": "2022-11-07T16:52:45Z"}, {"author": "Tony Li", "text": "

@Zongpeng Du That's wholly irrelevant. The location of the LB decision is entirely flexible.

", "time": "2022-11-07T16:53:20Z"}, {"author": "Daniel Bernier", "text": "

@Susan Hares you raised a good angle ... in my mind the effort ( and I have stated this before ) is how to make client/developers aware of capabilities in a manner they can be steered in the proper path.

", "time": "2022-11-07T16:53:50Z"}, {"author": "Andrew Alston", "text": "

@Martin Vigoureux the gap analysis may eliminate one or two potential existing solutions - but I really don\u2019t believe that it eliminates all of the ways

", "time": "2022-11-07T16:54:34Z"}, {"author": "Daniel Bernier", "text": "

and make them aware / queried in a manner that is not orthogonal to their developer experience

", "time": "2022-11-07T16:55:10Z"}, {"author": "Martin Vigoureux", "text": "

Ok. But then should we look into extending these?

", "time": "2022-11-07T16:55:31Z"}, {"author": "Zongpeng Du", "text": "

I think the ingress nodes nowadays can not obtain the service information and do LB accordingly.

", "time": "2022-11-07T16:55:55Z"}, {"author": "Cheng Li", "text": "

multiple solutions can coexist, meaning we can provide different solutions from different layers or angles. welcome people to discuss the gap analysis in dyncast or can mail list.

", "time": "2022-11-07T16:55:56Z"}, {"author": "Cheng Li", "text": "

again, if we do not read the draft, and discuss in the mailing list, it is nearly impossible to understand each other in short time.

", "time": "2022-11-07T16:56:28Z"}, {"author": "Jari Arkko", "text": "

FWIW I agree with Tony Li's point about scope. It is unclear to me why routing layer is the right place for a solution in this case; I do agree that having more factors brought in for making a load balancing decision is very useful. But we need to look at where doing this is most beneficial.

", "time": "2022-11-07T16:58:19Z"}, {"author": "Susan Hares", "text": "

@tony-Li - how many LB in this scenario? I cannot tell.

", "time": "2022-11-07T16:59:04Z"}, {"author": "Stewart Bryant", "text": "

If there is more than one LB won't they fight each other?

", "time": "2022-11-07T16:59:45Z"}, {"author": "Tommaso Pecorella", "text": "

I can\u2019t wait to install a malicious LB

", "time": "2022-11-07T17:00:30Z"}, {"author": "Darren Dukes", "text": "

After reading the problem statement there are a three example services - AR/VR, digital twin, vehicles.
\nthe gap analysis does talk about these use cases but I'm not seeing how the existing solutions are used in the use cases and are currently failing.
\nThe charter proposal didn't crystalize this for me either.

", "time": "2022-11-07T17:00:48Z"}, {"author": "Cheng Li", "text": "

it is good to see that you agree that having more factors brought in for making decisions. How to do it is the solution we should discuss further. Regarding LB, please read the LB related gap analysis.

", "time": "2022-11-07T17:01:00Z"}, {"author": "Antoine Fressancourt", "text": "

One aspect application or upper layer solution often fail to achieve is dynamicity. Besides, I have a bias against tunnels and re-encapsulation. All in all, it is about choosing a path to a destination, this is the seminal definition of routing.

", "time": "2022-11-07T17:01:03Z"}, {"author": "Darren Dukes", "text": "

Darren Dukes said:

\n
\n

After reading the problem statement there are a three example services - AR/VR, digital twin, vehicles.
\nthe gap analysis does talk about these use cases but I'm not seeing how the existing solutions are used in the use cases and are currently failing.
\nThe charter proposal didn't crystalize this for me either.

\n
\n

I'm entering this here since the queue is closed and I expect there may be better discussion on the list after the BOF for this work. It would be interesting to see what I'm missing or if the current drafts could be improved.

", "time": "2022-11-07T17:01:43Z"}, {"author": "Ketan Talaulikar", "text": "

@Antoine choosing a path to a destination is within routing. Is choosing the destination IP itself also within routing?

", "time": "2022-11-07T17:02:02Z"}, {"author": "Tommaso Pecorella", "text": "

Seriously, security will be a nightmare (but I love to call them opportunities)

", "time": "2022-11-07T17:02:16Z"}, {"author": "Zongpeng Du", "text": "

When notifying the service info, some security method can be used if needed.

", "time": "2022-11-07T17:02:53Z"}, {"author": "Dirk Trossen", "text": "

Darren Dukes said:

\n
\n

After reading the problem statement there are a three example services - AR/VR, digital twin, vehicles.
\nthe gap analysis does talk about these use cases but I'm not seeing how the existing solutions are used in the use cases and are currently failing.
\nThe charter proposal didn't crystalize this for me either.

\n
\n

Fair point and it will need to be shown more, but there's a reference to work being discussed at the mentioned side meeting on Wednesday where we compared on vs off path solutions and it shows the impact of using either.

", "time": "2022-11-07T17:03:17Z"}, {"author": "Tony Li", "text": "

@Susan Hares It would seem to me that this call for a distributed LB front end: each ingress node needs to make a LB decision and then distribute that. If the handset is handed off to another ingress, the requirements request that the previous LB decision be retained. Yes, this is new technology. Yes, it is distributed. The OSPF LSDB is not the right place to carry that data. The IGP is not a dump truck.

", "time": "2022-11-07T17:03:22Z"}, {"author": "Darren Dukes", "text": "

Ketan Talaulikar said:

\n
\n

@Antoine choosing a path to a destination is within routing. Is choosing the destination IP itself also within routing?

\n
\n

In other load balancing systems an encapsulation would be used but that's going into solutions... Was there mention of changing a destination address Ketan?

", "time": "2022-11-07T17:03:25Z"}, {"author": "Antoine Fressancourt", "text": "

It depends on your definition of a destination. A moving / abstract target is still a destination in my view, and this view is backed by numerous future Internet research

", "time": "2022-11-07T17:03:39Z"}, {"author": "Cheng Li", "text": "

choosing a path or imparting a routing decision should be a RTG area problem, I do not understand why this is not clear :(

", "time": "2022-11-07T17:03:44Z"}, {"author": "Ketan Talaulikar", "text": "

@ Antoine my definition of destination is the IP dst address in the IP packet sent from the end system.

", "time": "2022-11-07T17:04:34Z"}, {"author": "Tony Li", "text": "

@Cheng Li You are not making a routing decision. You are making a server selection.

", "time": "2022-11-07T17:05:20Z"}, {"author": "Antoine Fressancourt", "text": "

@Ketan the \u00ab\u00a0locator\u00a0\u00bb IP address or the \u00ab\u00a0identifier\u00a0\u00bb IP address :-) ?

", "time": "2022-11-07T17:05:45Z"}, {"author": "Susan Hares", "text": "

@Jari - do you agree with Tony Li that this is setting up communication between LBs?

", "time": "2022-11-07T17:05:50Z"}, {"author": "Jaehoon Paul Jeong", "text": "

Comments from Jaehoon Paul Jeong

\n
    \n
  1. \n

    CAN BoF needs to consider energy consumption in edge cloud servers as computing resources because energy is an important aspect in the viewpoint of operators.

    \n
    2. \n
  2. \n

    As another use case, CAN can consider the safe flying service for Urban Air Mobility (UAM) as flying cars because many car vendors such as Hyundai are working for commercializing UAM around 2018.

    \n
    3. \n
  3. \n

    For proactive edge server assignments for moving hosts like UEs, the mobility information of UEs and the profile of their applications can be used to estimate the trajectory for resource assignment and migration of services along with the required resource demands and delay requirements.

    \n
    4. \n
", "time": "2022-11-07T17:05:51Z"}, {"author": "Antoine Fressancourt", "text": "

If it is the former, is mobile IP belonging to routing ?

", "time": "2022-11-07T17:06:38Z"}, {"author": "Darren Dukes", "text": "

@Dirk Trossen Thanks, I look forward to Wednesdays clarifications.

", "time": "2022-11-07T17:06:46Z"}, {"author": "Ketan Talaulikar", "text": "

@Antoine It is the 32-bit/128-bit in the destination of the IP packet. That is the \"server selection\" unless we are talking anycast and all servers have the same IP.

", "time": "2022-11-07T17:08:08Z"}, {"author": "Jari Arkko", "text": "

+1 to what Cullen just said. Lets share information and make decisions, but avoid putting too many complex things in the routing layer.

", "time": "2022-11-07T17:09:23Z"}, {"author": "Zongpeng Du", "text": "

the servers offering the same service can have the same IP

", "time": "2022-11-07T17:09:57Z"}, {"author": "Antoine Fressancourt", "text": "

@Zongpeng Du my point exactly

", "time": "2022-11-07T17:10:38Z"}, {"author": "Stewart Bryant", "text": "

Surely only if the services are stateless?

", "time": "2022-11-07T17:11:06Z"}, {"author": "Tony Li", "text": "

That seems like it's assuming one particular solution property and then convoluting the architecture to make it work.

", "time": "2022-11-07T17:11:44Z"}, {"author": "Zongpeng Du", "text": "

if the routing layer can benefit on the efficiency, why not consider it?

", "time": "2022-11-07T17:13:01Z"}, {"author": "Tony Li", "text": "

What are the abstract requirements? What are the inherent functions that are required? How should they be arranged?

", "time": "2022-11-07T17:13:15Z"}, {"author": "Tony Li", "text": "

The routing layer will not benefit from the efficiency.

", "time": "2022-11-07T17:13:31Z"}, {"author": "Susan Hares", "text": "

@Tony - This distributed LB is not a good solution for IGPs for network layer connectivity. If you are running a LB distribution SPF in APP or TSV layer, in loosely coupled system with IGP - this has better scaling properties. The type of algorithms that work depend on scale of LBs. Hence my question.

", "time": "2022-11-07T17:13:50Z"}, {"author": "Tony Li", "text": "

Yes, you can piggy back this problem on top of the routing protocols. That doesn't make it good architecture. That makes about as much sense as playing battleship with BGP.

", "time": "2022-11-07T17:14:16Z"}, {"author": "Tony Li", "text": "

@Susan Hares AFAICT, an SPF is not required. :-)

", "time": "2022-11-07T17:15:29Z"}, {"author": "Susan Hares", "text": "

@Tony Li: On SPF, it is not required. Best tools depend on topology + size of LB topology + type of changes.

", "time": "2022-11-07T17:19:01Z"}, {"author": "Adnan Rashid", "text": "

Question 1, I am not clear

", "time": "2022-11-07T17:19:19Z"}, {"author": "Zongpeng Du", "text": "

BGP can be used to convey the service info, some work has be done. And it is straightforward when the target/decision point is a router.

", "time": "2022-11-07T17:19:50Z"}, {"author": "Susan Hares", "text": "

@Zongpeng - stating you put in BGP does not answer Tony LI's or my point.

", "time": "2022-11-07T17:20:59Z"}, {"author": "Antoine Fressancourt", "text": "

@Zongpeng Du I think BGP is one of the solutions used in kubernetes clusters to route to a proper instance

", "time": "2022-11-07T17:21:22Z"}, {"author": "Darren Dukes", "text": "

One example of the gap analysis that make me question its applicability to the use cases are statements like this :

\n
The second way is to deploy an individual load balancer in\n   each site, with its scope of application only to service instances in\n   the site.  It is still relatively easy to deploy.  But, its main\n   deficiency lies in no more inter-site load balancing that could\n   prevent the achievement of better traffic steering across sites.\n
\n

Is this true? If I forward all traffic to a set of services through an on-site load balancer is it impossible for that load balancer to balance to different sites? I'll send this to the list too, maybe we can improve this topic in the gap analysis.
\nMaybe a WG to investigate the problem space would be a good start?

", "time": "2022-11-07T17:23:03Z"}, {"author": "Tony Li", "text": "

That's assuming conventional load balancing. That's an inappropriate assumption.

", "time": "2022-11-07T17:23:35Z"}, {"author": "Tony Li", "text": "

We hire ADs to make area decisions....

", "time": "2022-11-07T17:25:51Z"}, {"author": "Susan Hares", "text": "

@Antoine - Just because an app puts it in BGP, it does not mean it is a good idea.

", "time": "2022-11-07T17:26:12Z"}, {"author": "Tony Li", "text": "

Should we serve web pages over BGP? We could...

", "time": "2022-11-07T17:26:44Z"}, {"author": "Antoine Fressancourt", "text": "

@Susan Hares Believe me, I don\u2019t think it is a good idea, and when I first heard about it I thought it would fail, but, hey, it is in production on large clusters now.

", "time": "2022-11-07T17:28:30Z"}, {"author": "Daniel Bernier", "text": "

@antoine k8s uses various ways to do things a better way of looking at the mechanics is service meshes at the app layer

", "time": "2022-11-07T17:28:32Z"}, {"author": "Tony Li", "text": "

@Antoine Fressancourt Did they have to extend BGP to do it?

", "time": "2022-11-07T17:28:59Z"}, {"author": "Daniel Bernier", "text": "

I 200% agree with Dino, if it becomes to complex, app devs will just tunnel in AMQP (non-IETF) or QUIC, etc

", "time": "2022-11-07T17:29:26Z"}, {"author": "Antoine Fressancourt", "text": "

I think BGP is liberal enough to convey proprietary messages and take according routing decisions

", "time": "2022-11-07T17:29:56Z"}, {"author": "Ryo Yanagida", "text": "

That sounds almost like saying IPv6 have enough bits to address individual frames in a video.

", "time": "2022-11-07T17:30:43Z"}, {"author": "Tony Li", "text": "

If you wanna solve this using non-standard proprietary hacks, please go right ahead.

", "time": "2022-11-07T17:30:55Z"}]