[{"author": "Anthony Somerset", "text": "

looks like meeting was moved from Liberty C to Liberty D?

", "time": "2022-07-26T19:04:20Z"}, {"author": "Jen Linkova", "text": "

it is listes as Libery D in the agenda

", "time": "2022-07-26T19:05:31Z"}, {"author": "Dhruv Dhody", "text": "

@meetecho - can you move the video to the speaker in the room

", "time": "2022-07-26T19:05:58Z"}, {"author": "Dhruv Dhody", "text": "

Thanks!

", "time": "2022-07-26T19:06:23Z"}, {"author": "Anthony Somerset", "text": "

Jen Linkova said:

\n
\n

it is listes as Libery D in the agenda

\n
\n

yes my original cal said Lib C though so, so maybe a semi-last minute change - for others also nearly caught out

", "time": "2022-07-26T19:06:55Z"}, {"author": "Dino Farinacci", "text": "

why is this proposal called msr6 when I haven't heard one word about source-routing or segment-routing?

", "time": "2022-07-26T19:19:05Z"}, {"author": "Dino Farinacci", "text": "

the slides should not refer to SD-WAN, SD-WAN is an industry term of proprietary overlays

", "time": "2022-07-26T19:22:05Z"}, {"author": "Dino Farinacci", "text": "

if you have referring to overlays developed by the IETF, then use the names the IETF has chosen

", "time": "2022-07-26T19:22:26Z"}, {"author": "Dino Farinacci", "text": "

rings have unnecessary latency

", "time": "2022-07-26T19:23:30Z"}, {"author": "Dino Farinacci", "text": "

the solution MUST build an acyclic distribution tree

", "time": "2022-07-26T19:24:06Z"}, {"author": "Yisong Liu", "text": "

Thank you Dino. SD WAN in the slides just refer to overlays

", "time": "2022-07-26T19:25:08Z"}, {"author": "Dino Farinacci", "text": "

are you building a new overlay architecture or using existing IETF overlays?

", "time": "2022-07-26T19:25:44Z"}, {"author": "Feng Yang", "text": "

SD-WAN is overlay network, in overlay/underlay point of view, it is limited domain.

", "time": "2022-07-26T19:29:21Z"}, {"author": "Juliusz Chroboczek", "text": "

I'm a little confused. On slide 2, the speaker mentioned IPsec. That's a concrete technology, right? Is it therefore not part of the solution domain rather than the problem statement?

", "time": "2022-07-26T19:30:36Z"}, {"author": "Jen Linkova", "text": "

@Dino: as we are late, would you mind if your question is answered on the chat?

", "time": "2022-07-26T19:30:52Z"}, {"author": "Zhenbin Li", "text": "

@Dina SDWAN is one usecase of MSR6. MSR6 is ont only for overlay.

", "time": "2022-07-26T19:31:18Z"}, {"author": "Dino Farinacci", "text": "

no prob Jen, answering inline here is fine with me

", "time": "2022-07-26T19:32:41Z"}, {"author": "Dino Farinacci", "text": "

@shenbin, its not a use-case, its a mechanim/solution

", "time": "2022-07-26T19:33:40Z"}, {"author": "Dino Farinacci", "text": "

so you seem to imply you are going to have both native and overlay solutions?

", "time": "2022-07-26T19:33:54Z"}, {"author": "Zhenbin Li", "text": "

Yes. It is.

", "time": "2022-07-26T19:34:26Z"}, {"author": "Anthony Somerset", "text": "

please request speakers to speak louder - its quiet even in the room

", "time": "2022-07-26T19:35:17Z"}, {"author": "Anthony Somerset", "text": "

or at least speak properly into the mic, thanks

", "time": "2022-07-26T19:35:33Z"}, {"author": "Cheng Li", "text": "

the volume is low,please keep closer to the mike

", "time": "2022-07-26T19:35:54Z"}, {"author": "Aijun Wang", "text": "

Hi, I am Aijun Wang from China Telecom. Here I want to give another example for multicast services existing within the network: currently, the live stream exist not only within the 5G transport network, It will also span multidomain, which are under the control of one service provider, also in limited-domain. In such scenario, the mulitcast source will locate in one Metro network, and the receivers will located in another Metro networks. The multicast traffic needs to span multiple domains, and there are aslo numberous live stream servies, and thousands/ten thousnds of receivers.

\n

Currently such live streams services are provided by CDN, we think the service provider should and can provide such multicast services to the customers

", "time": "2022-07-26T19:37:54Z"}, {"author": "Dino Farinacci", "text": "

I am overwhelmed by this slide!

", "time": "2022-07-26T19:38:12Z"}, {"author": "Dino Farinacci", "text": "

it proves, we have develop something very wrong

", "time": "2022-07-26T19:38:25Z"}, {"author": "Suresh Krishnan", "text": "

@Dino: I think this the \"Before\" slide :)

", "time": "2022-07-26T19:39:36Z"}, {"author": "Dino Farinacci", "text": "

how one of the goals of this BOF is to develop the simpliest solution so there can be reliable deployment. That means, what Shep said, what are the requirements that today's solution cannot do

", "time": "2022-07-26T19:39:51Z"}, {"author": "Dino Farinacci", "text": "

@suresh, thank goodness

", "time": "2022-07-26T19:40:03Z"}, {"author": "Antoine Fressancourt", "text": "

Simplifying this architectural complexity by treating some protocols as overlay was a point in DT\u2019s Terrastream architecture

", "time": "2022-07-26T19:40:15Z"}, {"author": "Zhenbin Li", "text": "

It proves we have to segment the network domain because of scale, at the same time we must make a easy way to crross multi-domains. @Dina

", "time": "2022-07-26T19:40:40Z"}, {"author": "Zhenbin Li", "text": "

@Dino

", "time": "2022-07-26T19:40:47Z"}, {"author": "Dino Farinacci", "text": "

@zhenbin, what if you have 100K receivers across 6 continents, segmentation doesn't help you

", "time": "2022-07-26T19:41:36Z"}, {"author": "Dino Farinacci", "text": "

where the Internet is now in its revolution and if you want multicast packets to travel across continents or across service providers, you have to use overlays

", "time": "2022-07-26T19:42:52Z"}, {"author": "Zhenbin Li", "text": "

This is the usecase beyond MSR6 in my opinon. How to create a Internet-based multicast.

", "time": "2022-07-26T19:43:06Z"}, {"author": "Dino Farinacci", "text": "

s/revolution/evolution

", "time": "2022-07-26T19:43:10Z"}, {"author": "Dino Farinacci", "text": "

@zhenbin, can you succinctly describe the MSR6 use-case, just pick one (not all you think would want) that is simple to explain

", "time": "2022-07-26T19:44:33Z"}, {"author": "Aijun Wang", "text": "

MSR6 focus on the solutions on limited domain

", "time": "2022-07-26T19:45:05Z"}, {"author": "Aijun Wang", "text": "

@Dino, please see my additional example

", "time": "2022-07-26T19:45:24Z"}, {"author": "Xuesong Geng", "text": "

@Dino, the use cases for MSR6 are classified into 3 types: underlay multicast in large scale network, overlay multicast and host initiated multicast

", "time": "2022-07-26T19:47:17Z"}, {"author": "Jeff Tantsura", "text": "

Most data centers are moving to SRv6???

", "time": "2022-07-26T19:48:40Z"}, {"author": "Dino Farinacci", "text": "

if you think SD-WAN can solve this problem, and other overlays, you should have added LISP to the list

", "time": "2022-07-26T19:48:57Z"}, {"author": "Dino Farinacci", "text": "

@aijun, your answer lacks any useful detail

", "time": "2022-07-26T19:49:30Z"}, {"author": "Dino Farinacci", "text": "

@xuesong, I understand, but why? We have those 3 types of solutions (not use-cases) today

", "time": "2022-07-26T19:50:34Z"}, {"author": "J\u00e1nos Farkas", "text": "

I guess \"zero delay\" means \"no switchover time\" (e.g., from primary to backup

", "time": "2022-07-26T19:50:54Z"}, {"author": "Juliusz Chroboczek", "text": "

Jeff: re SRv6, do you mean that you're surprised to learn that or that you know that is not the case? Genuinely trying to learn.

", "time": "2022-07-26T19:51:07Z"}, {"author": "Dino Farinacci", "text": "

@juliusz, there is no way to solve that unless you replicated to both and have one drop

", "time": "2022-07-26T19:51:28Z"}, {"author": "Dino Farinacci", "text": "

and you need signaling to tell the multiple places on who drops and who forwards

", "time": "2022-07-26T19:51:48Z"}, {"author": "Juliusz Chroboczek", "text": "

My question was about SR. Is it not actually being used?

", "time": "2022-07-26T19:52:02Z"}, {"author": "Dino Farinacci", "text": "

see draft-ietf-lisp-predictive-rlocs for details on zero-loss switchover for mobility

", "time": "2022-07-26T19:52:09Z"}, {"author": "Jingrong Xie", "text": "

For 100k receivers across 6 continents, it may need a hierarchy stateless multicast in overlay -- first replicate to 100 rigions across 6 continents, then 10010 to relays(SFUs), and lasty 10010*100 hosts. will that make sense @dino

", "time": "2022-07-26T19:52:19Z"}, {"author": "Dino Farinacci", "text": "

right @jingrong, so only use one solution, you build for the scale, and for the smaller cases, you use that SAME solution to scale down

", "time": "2022-07-26T19:53:02Z"}, {"author": "Jingrong Xie", "text": "

yes, I think it is one solution for different use cases

", "time": "2022-07-26T19:53:35Z"}, {"author": "Juliusz Chroboczek", "text": "

Who is Greg with the tie-died t-shirt?

", "time": "2022-07-26T19:53:35Z"}, {"author": "Dino Farinacci", "text": "

that is Shep, a multi-decade multicast deployment engineer

", "time": "2022-07-26T19:53:59Z"}, {"author": "Adrian Farrel", "text": "

aka Greg Shepherd

", "time": "2022-07-26T19:54:21Z"}, {"author": "Cheng Li", "text": "

we need people to state the name and company before speaking, hard to write the minutes.

", "time": "2022-07-26T19:54:22Z"}, {"author": "Juliusz Chroboczek", "text": "

Thanks, Adrian.

", "time": "2022-07-26T19:54:41Z"}, {"author": "Dino Farinacci", "text": "

BIER requires hardware changes in underlay routers

", "time": "2022-07-26T19:55:13Z"}, {"author": "Dino Farinacci", "text": "

BIER belongs in the core to get the best benefit, and its a great benefit to avoid the RPF switchover problem which many implementors struggle with

", "time": "2022-07-26T19:56:11Z"}, {"author": "Dino Farinacci", "text": "

he left out DVMRP in the list of [MOSPF, DMVPN, ...]

", "time": "2022-07-26T19:57:49Z"}, {"author": "Aijun Wang", "text": "

@Dino, here is some detail information: The service provider has about hundreds of Metro Networks that connected by the backbone. There may be hundreds devices in each Metro domains. The receives may locates in any of these Metro network.

\n

The multicast service/live stream should start from one access point of the Metro Network, via the backbone and to the receivers in any of the Metro Networks.

\n

The multicast packets should reach ten thousands of the access devices that located in the hundreds of the Metro Network.

\n

There are ten thousannds of the live strems at the same time

", "time": "2022-07-26T19:58:10Z"}, {"author": "Xuesong Geng", "text": "

@Dina, there are existing solutions but with limitations respectively in different aspects, for example: maintaining multicast status in intermediate nodes which doesn't scale to the number of multicast services or not scale to the network size which requests bit position for each egress nodes

", "time": "2022-07-26T19:58:11Z"}, {"author": "Dino Farinacci", "text": "

DVMRP more relevant because not vendor specific (DMVPN is cisco)

", "time": "2022-07-26T19:58:19Z"}, {"author": "Dino Farinacci", "text": "

@aijun, the topology doesn't matter, its the number of sources and receivers for a group that is the challenge to meet

", "time": "2022-07-26T19:59:20Z"}, {"author": "Dino Farinacci", "text": "

but thank you for specifying receiver size

", "time": "2022-07-26T20:00:00Z"}, {"author": "Dino Farinacci", "text": "

@xuesong, that is why you have to have overlays with engineered distribution branches

", "time": "2022-07-26T20:00:57Z"}, {"author": "Xuesong Geng", "text": "

That is motivation of source routing; also it will benefit host-initiated, because the multicast tree could be encoded in the source host

", "time": "2022-07-26T20:00:59Z"}, {"author": "Donald Eastlake", "text": "

The V1.0 slides are being presented. There are V1.1 slides!

", "time": "2022-07-26T20:01:05Z"}, {"author": "Dino Farinacci", "text": "

meaning, you don't have to use ALL the solutions Toerless just outlined but the right ones

", "time": "2022-07-26T20:01:29Z"}, {"author": "Dino Farinacci", "text": "

simple, less is better

", "time": "2022-07-26T20:01:34Z"}, {"author": "Yisong Liu", "text": "

@Dino the topology size affects the overhead of stateless multicast solution

", "time": "2022-07-26T20:03:04Z"}, {"author": "Dino Farinacci", "text": "

this diagram certainly looks like hop-by-hop, how long do you want to take to deploy this, 10 years?

", "time": "2022-07-26T20:03:06Z"}, {"author": "Aijun Wang", "text": "

@Dino, Topology has also influence to the solution. We all know that there are no simple solution for the inter-domain multicast services now

", "time": "2022-07-26T20:04:32Z"}, {"author": "Xuesong Geng", "text": "

@Dino, yes..the simple and unified solution for this why we try to introduce msr6 to cover these requirements

", "time": "2022-07-26T20:04:42Z"}, {"author": "Dino Farinacci", "text": "

@aijun, do you want the receivers and sources to move while they are receiving/sending to the group?

", "time": "2022-07-26T20:05:34Z"}, {"author": "Dino Farinacci", "text": "

@xuesong, you have to prove that, not just state it

", "time": "2022-07-26T20:06:03Z"}, {"author": "Aijun Wang", "text": "

firstly, we will focus on the non-moving scenarios, but in limited inter-domain solution. I think the move of receivers can be easily solved, what they need do is just the join/leave the access points. The move of the source has to study more carefully, for example, the path should be recalculated

", "time": "2022-07-26T20:09:12Z"}, {"author": "Dino Farinacci", "text": "

then the topology doesn't matter

", "time": "2022-07-26T20:09:45Z"}, {"author": "Yisong Liu", "text": "

@Dino per-flow state solution may be not affected by topology, but the source and the group number affects the overhead of per-flow state solutions. so we want a simple solution to solve all of these problems and also in native IPv6 network.

", "time": "2022-07-26T20:09:46Z"}, {"author": "Dino Farinacci", "text": "

@yisong, yes, agree, and that is what the solution should focus on

", "time": "2022-07-26T20:11:13Z"}, {"author": "Aijun Wang", "text": "

For topology, what we want to emphasize is that the size of the network and intra- or inter-domain

", "time": "2022-07-26T20:12:01Z"}, {"author": "Xuesong Geng", "text": "

@Dino, I think the solution is quite straight forward to show how these requirements are satisfied. Just like segment routing for unicast, similar functionalities could be provided in MSR6

", "time": "2022-07-26T20:13:05Z"}, {"author": "Dino Farinacci", "text": "

it is not clear how much header space you will use with SR6

", "time": "2022-07-26T20:14:20Z"}, {"author": "Dino Farinacci", "text": "

there is a lot of overhead

", "time": "2022-07-26T20:14:25Z"}, {"author": "Dino Farinacci", "text": "

and if you don't think that is true, ask the authors of SRv6, who are now working on header compression, that is an admission of large headers

", "time": "2022-07-26T20:14:51Z"}, {"author": "Xuesong Geng", "text": "

it depends on the scenario

", "time": "2022-07-26T20:15:06Z"}, {"author": "Adrian Farrel", "text": "

Can we please not call others disingenuous

", "time": "2022-07-26T20:15:20Z"}, {"author": "Dino Farinacci", "text": "

@xuesong, wrong answer, because if it is large headers at all, then its a non-starter for one of your scenarios

", "time": "2022-07-26T20:15:40Z"}, {"author": "Antoine Fressancourt", "text": "

hardly more overhead than most encapsulation mechanisms used to solve part of the problem space punctually

", "time": "2022-07-26T20:15:41Z"}, {"author": "Xuesong Geng", "text": "

if you have a very large network with a multiple sparse multicast trees

", "time": "2022-07-26T20:16:04Z"}, {"author": "Xuesong Geng", "text": "

it show the benefits

", "time": "2022-07-26T20:16:17Z"}, {"author": "Dino Farinacci", "text": "

@adrian, I don't know if that was directed to me, but I did no such thing, you may have interpreted it that way, but was not the sender's intent

", "time": "2022-07-26T20:16:22Z"}, {"author": "Juliusz Chroboczek", "text": "

Dino, I noticed the comment too, and it wasn't you.

", "time": "2022-07-26T20:16:52Z"}, {"author": "Adrian Farrel", "text": "

@Dino. It was GregS at the mic. And unacceptable

", "time": "2022-07-26T20:17:28Z"}, {"author": "Juliusz Chroboczek", "text": "

It was an unrelated comment at the mike.

", "time": "2022-07-26T20:17:41Z"}, {"author": "Antoine Fressancourt", "text": "

@Adrian Farrel agreed

", "time": "2022-07-26T20:17:46Z"}, {"author": "Dino Farinacci", "text": "

@andrian, ack

", "time": "2022-07-26T20:18:54Z"}, {"author": "Dino Farinacci", "text": "

if toerless thinks this is just IPv6, then there is no new solution that needs to be proposed, right?

", "time": "2022-07-26T20:23:14Z"}, {"author": "Dino Farinacci", "text": "

if the authors, can say what they want to ADD, then it would be more clear what's new

", "time": "2022-07-26T20:23:49Z"}, {"author": "Anthony Somerset", "text": "

i still have no understanding of what the gaps and problems are - no one has attempted to address this

", "time": "2022-07-26T20:25:38Z"}, {"author": "Dino Farinacci", "text": "

@anthony, agree as well

", "time": "2022-07-26T20:26:45Z"}, {"author": "Juliusz Chroboczek", "text": "

Who's the person at the mike?

", "time": "2022-07-26T20:27:24Z"}, {"author": "Adrian Farrel", "text": "

Tom Hill

", "time": "2022-07-26T20:27:43Z"}, {"author": "Juliusz Chroboczek", "text": "

ty

", "time": "2022-07-26T20:27:47Z"}, {"author": "Dino Farinacci", "text": "

I think DT

", "time": "2022-07-26T20:27:52Z"}, {"author": "Anthony Somerset", "text": "

BT

", "time": "2022-07-26T20:28:06Z"}, {"author": "Dino Farinacci", "text": "

@anthony, stand correct, thanks

", "time": "2022-07-26T20:28:54Z"}, {"author": "Aijun Wang", "text": "

@anthony, @dino. the gap is that the current solutions can't meet the three core use cases at the same time

", "time": "2022-07-26T20:29:45Z"}, {"author": "Xuesong Geng", "text": "

There are 3 main gaps, which I think is clearly pointed out in the 1st presentation: 1. scalability for both network scale and number of services; 2. Host-initiated multicast with no state in the intermediate nodes; 3. P2MP security in some overly cases

", "time": "2022-07-26T20:29:48Z"}, {"author": "Dino Farinacci", "text": "

@aijun, you have to deep dive what you mean, stating it in a binary fashion (either it works or doesn't work) isn't useful to explain your position

", "time": "2022-07-26T20:31:00Z"}, {"author": "Cheng Li", "text": "

I think the SRv6 is unreleated topic? it looks to me it is about IPv6 based, not SRv6 based. No sure

", "time": "2022-07-26T20:31:04Z"}, {"author": "Juliusz Chroboczek", "text": "

Okay, that's the second time this point is being made by apparently knowledgeable people. Could somebody please, please point me at an article that describes the problems with SR?

", "time": "2022-07-26T20:31:06Z"}, {"author": "Dino Farinacci", "text": "

If you use existing overlays in the hosts (i.e. LISP) you will solve all 3 problems with one solution, which means you head-end-replicate to L3 replication points in the network and native multicast at the edges (on the RAN)

", "time": "2022-07-26T20:32:13Z"}, {"author": "Xuesong Geng", "text": "

I think we pay too much attention on IPv6/SRv6, which is just treated as a container which supports extension capability for flexible encoding with new type of Routing Header

", "time": "2022-07-26T20:32:16Z"}, {"author": "Dino Farinacci", "text": "

have you guys read the LISP multicast documents?

", "time": "2022-07-26T20:32:42Z"}, {"author": "Dino Farinacci", "text": "

we have spent a lot of time on it post native multicast years

", "time": "2022-07-26T20:32:54Z"}, {"author": "Dino Farinacci", "text": "

so we have learned of the problems and attempted to fix them

", "time": "2022-07-26T20:33:05Z"}, {"author": "Dino Farinacci", "text": "

we deprecated IPv4 source-routing because we could only get 14 hops, that bug turned out to be a feature, or we would have wasted more header space LOL

", "time": "2022-07-26T20:33:56Z"}, {"author": "Suresh Krishnan", "text": "

@meetecho: small issue with the queue

", "time": "2022-07-26T20:35:01Z"}, {"author": "Suresh Krishnan", "text": "

The room network was a bit unstable

", "time": "2022-07-26T20:35:11Z"}, {"author": "Lorenzo Miniero", "text": "

What's wrong?

", "time": "2022-07-26T20:35:15Z"}, {"author": "Suresh Krishnan", "text": "

and the queue got reordered

", "time": "2022-07-26T20:35:16Z"}, {"author": "Suresh Krishnan", "text": "

The in room person at the top of the queue got bumped to the bottom

", "time": "2022-07-26T20:35:29Z"}, {"author": "Suresh Krishnan", "text": "

behind all the remote participants who were in line after him

", "time": "2022-07-26T20:35:44Z"}, {"author": "Suresh Krishnan", "text": "

The queue probably needs a hold down timer to prevent flapping.

", "time": "2022-07-26T20:36:57Z"}, {"author": "Cheng Li", "text": "

many people in the online queue, it may be good to hear people from online as well.

", "time": "2022-07-26T20:36:57Z"}, {"author": "Lorenzo Miniero", "text": "

We'll check what's wrong, thanks for the heads up!

", "time": "2022-07-26T20:37:12Z"}, {"author": "Suresh Krishnan", "text": "

@Cheng Li we have a unified queue

", "time": "2022-07-26T20:37:22Z"}, {"author": "Cheng Li", "text": "

thank you @suresh

", "time": "2022-07-26T20:37:35Z"}, {"author": "Suresh Krishnan", "text": "

@Dino, please join the queue

", "time": "2022-07-26T20:39:01Z"}, {"author": "Suresh Krishnan", "text": "

we reopened it

", "time": "2022-07-26T20:39:05Z"}, {"author": "Dino Farinacci", "text": "

why does multicast scale? because receiver state is not tracked, if you require the source to know about receivers, its a non-starter, look at ST2 from the mid-80s where source initiated trees failed

", "time": "2022-07-26T20:39:49Z"}, {"author": "Anthony Somerset", "text": "

i do think the tiktok/instagram use is flawed - those networks are pretty much purely on demand, its not live TV - multicast wouldn't work here at all

", "time": "2022-07-26T20:41:50Z"}, {"author": "Jabber", "text": "

MichaelRichardson: tiktok has live events, or wants to, from what I understand.

", "time": "2022-07-26T20:43:03Z"}, {"author": "Cheng Li", "text": "

live events needs multicast actually

", "time": "2022-07-26T20:43:18Z"}, {"author": "Xuesong Geng", "text": "

@Anthony They are 2 different cases, live channel and on-demand short video

", "time": "2022-07-26T20:43:18Z"}, {"author": "Anthony Somerset", "text": "

live yes - but the huge bulk of those services are on demand and viewed at different times by different people

", "time": "2022-07-26T20:43:54Z"}, {"author": "Xuesong Geng", "text": "

Multicast is just for the live channel

", "time": "2022-07-26T20:43:54Z"}, {"author": "Darren Dukes", "text": "

@anthony I have teen kids :) Tiktok etc do have a live broadcast modes.

", "time": "2022-07-26T20:43:59Z"}, {"author": "Anthony Somerset", "text": "

i'd be curious to understand how huge providers like Youtube solve this problem today in the live mode

", "time": "2022-07-26T20:44:46Z"}, {"author": "Cheng Li", "text": "

It may be crazy for some people that some live event may has over 1 Billion watchers....

", "time": "2022-07-26T20:44:56Z"}, {"author": "Suresh Krishnan", "text": "

@Anthony: The OTT providers will most likely use only unicast

", "time": "2022-07-26T20:45:23Z"}, {"author": "Juliusz Chroboczek", "text": "

Anthony: HLS + massive CDNs, and pretend that 5s latency is live streaming?

", "time": "2022-07-26T20:46:04Z"}, {"author": "Anthony Somerset", "text": "

thats my point...

\n

I'm just trying to get to a point where we actually have something to match the first point of the bof goals:

\n

\" there is a problem that needs solving\"

\n

from what i can see there are problems that can already be solved by existing technologies - i am not seeing anything that demonstrates where something is missing in existing technologies/standards

", "time": "2022-07-26T20:47:43Z"}, {"author": "Yisong Liu", "text": "

@anthony short live video live like tiktok, only provide low bitrate video if using unicast in network and the number of users is limited. but if using multicast the video quality can be improved and the users number can be unlimited.

", "time": "2022-07-26T20:47:51Z"}, {"author": "Jingrong Xie", "text": "

I have read LISP and LISP-bis, but have not read LISP multicast yet but will like to read.

", "time": "2022-07-26T20:48:24Z"}, {"author": "Dino Farinacci", "text": "

@jingrong, please send you reactions/comments to lisp@ietf.org and we will respond quickly

", "time": "2022-07-26T20:50:04Z"}, {"author": "Jingrong Xie", "text": "

sure thanks Dino

", "time": "2022-07-26T20:50:35Z"}, {"author": "Darren Dukes", "text": "

Disclaimer - I didn\u2019t read the solution drafts

\n

is the idea of \u201cmulticast source routing for ipv6\u201d to encode the entire multicast tree in an Ipv6 header so a multicast source sends a single packet for all receivers without adding any tree state to the network?

\n

Please forgive the ignorance.

", "time": "2022-07-26T20:51:00Z"}, {"author": "Jingrong Xie", "text": "

optionally the path of the entire multicast tree. not \"all receivers\" but may part of receivers.

", "time": "2022-07-26T20:52:23Z"}, {"author": "Jingrong Xie", "text": "

you can send 10 packets with each 1/10 of the receivers. @Darren

", "time": "2022-07-26T20:53:06Z"}, {"author": "Gyan Mishra", "text": "

@Janos yes zero delay means no switchover time

", "time": "2022-07-26T20:56:38Z"}, {"author": "Darren Dukes", "text": "

@jingrong So a combination of source replication and strict source routing for the stateless network.

", "time": "2022-07-26T20:57:27Z"}, {"author": "Gyan Mishra", "text": "

In the slide de

", "time": "2022-07-26T20:57:53Z"}, {"author": "Wim Henderickx", "text": "

There seems to be some history here + i have not read all the solution draft. Mea culpa. I have a fundamental q. Lets forget the encapsulation. If you look at the bier forwarding mechanism is there something new proposed here? In other words is this the bier fundamental framework encapsulated in a different way ?

", "time": "2022-07-26T20:59:06Z"}, {"author": "Anthony Somerset", "text": "

there needs to actually be a problem statement defined - not just use cases

", "time": "2022-07-26T20:59:21Z"}]