Internet Engineering Task Force IETF 114, 25 Jul 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF114-BIER-20220725-1400

Description

BIER meeting session at IETF114
2022/07/25 1400

https://datatracker.ietf.org/meeting/114/proceedings/

A

Hello, hello, can you hear me.

A

B

Hello, do you hear me.

C

Testing testing testing.

A

We are not alone.

C

Testing testing testing.

C

C

Testing testing.

B

You hear me, do you hear me.

A

A

D

Hi sandy, we can not hear you through the room. We currently have some issues here locally.

C

Tasting tasting testing just.

E

Yeah there, it is all right.

E

Okay, slow progress here.

E

Sandy test testing for sandy.

E

Nothing should be coming through here.

C

E

Okay sandy says hello.

A

E

All right we hear you can.

A

F

Yes, oh finally, okay.

E

I think it's the same thing: she's connected to a beat echo if it's coming to speakers.

E

How could it be she's only connected remotely echo.

E

Okay: let's go to materials; let's get this thing.

E

That's got the agenda anyway. Doesn't it it should agenda, it does all.

G

E

um Let's move this bike over here: we've done the test test test, we think we're functional. It appears from what we can tell. We can hear each other on both ends, and I think I've got this thing running like it's supposed to that doesn't mean I'm correct.

E

I only have a delusion of fat correct right now, so considering that time is, we should probably get this rolling. um I have not certain how the blues work. I think you need to scan outside or scan this, and then that opens up. Does the auto blues like before so we get both remote and local, auto blues, which is pretty darn nice?

E

um This was supposed to oh, I'm not. I have to take over okay, I have to take over as display. I have to share screen video.

H

D

E

Sorry, my session got bumped out, I'm going to have to reconnect here so give me a second. I think we can reproduce that fairly confident, hey and I'm back in just waiting. My privileges.

E

E

So I open that up and I want to.

E

I'll attempt to share my screen and see if this works hold tight.

G

C

H

E

Okay, welcome to the beer working group. We are oh 12 and a half minutes delayed, not bad. Considering this the first session in the morning, we are not the only ones going through this confusion. uh Any working group chairs associated the laptop in the room is no longer controlling the slides.

E

It's just to control the mic and the camera in the room. Apparently it auto connects. You can log in with your own laptop control, the slides here. It's all right, just a little twist in the change so.

E

Here, let's see oh yeah no well required reading. Everyone noted well nods. It's 10 a.m, no matter where you came from shouldn't, be too sleepy, yet there's coffee around, so we can get there um minute, location and our journalism. Now we've got yeah.

E

We have volunteers to take minutes.

E

I

Such a wonderful place to you know success in life. Taking minutes to the idea teaches your relevant skills.

E

No it's another theresa moment. It's like feeding the poor, think I'll think of the enriching it's going to be for your life. Taking minutes for us.

E

He's looking at me, you have a volunteer. Do you see that man, volunteers.

E

So I think the tool is integrated. It can be done fairly. Quick with like this is not.

I

Taking too much just.

E

Go to the note taking tool just automatically puts it up there. So do you see where I'm showing that yeah there all right? We are there all right. So, let's look at the agenda. We've got uh status going through the drafts. What's in the last call, what's actually uh in the queue? What is expired? I was already called to my attention that there was another expired graph. That's actually ready and just need to be refreshed.

E

uh Stick's, gonna, refresh our memories on that get it back in the list, then we've got um multicast as a service extension headers and uh the bt gift id anything.

I

Missing, did you run status of the drafts? That's coming up next. This is just a minute here we go.

E

J

With no torque yeah uh tallest eckerd um just send email to you, folks that we've got the brte in auth48 yeah yeah, but then two weeks were really painful for all type of other stuff, so only become rfc after beer to e draft yeah dear earth 48 so will become rfc, but only after the itf okay, authors didn't get around to spending time.

E

Thank you all right, nothing missing all right! So, let's go to status.

E

We've got two here in the queue uh I'm not certain. I think these been around a while there's your terkas in the cube right. That's who you're talking about doorless, yeah, yeah, okay uh and bar ipa has been there a while too, I don't know we're waiting for a d at the time. Last I heard we also have some 80 comments outstanding for v3.

E

Now, a new draft multicast service, we'll hear about today and there's a beer fast, reroute draft that's been adopted as well.

E

In last call hbls, we need uh well need some review from what I understand. I think we had to go to idr for review on that too. Didn't we. I think we already had that in parallel.

I

E

Then, from there on it moves into a theme we need shepherds. We need document shepherds. uh We have our own man-man man here, who is uh in one of the reviews, we're waiting for his to be complete, php beer and six and prefix redistribution all need shepherds. It's a fairly straightforward process. There's a template! You go through q. A you know. Do some hunting around to make sure you're consistent with what the questions are list response and things?

E

But it's it's not a heavy lift. It's just something that shouldn't be done necessarily by the the authors of the draft. So we'll go to the list, we'll ask for volunteers again, everyone's looking down no one's even making eye contact so as.

C

E

K

Ask for there we go.

E

I got eye contact, you looking to be a shepherd yeah all right, so you know pick one we'll fire off the email list. You can respond to us then, or something and thank.

I

You so much, we need beer in six, because the uh babel and the national guys are picking up the issue again.

I

That will be hinging around this draft. This discussion thank.

E

You very much appreciate it, so he will not be paying for beer. The rest of the week see that see what you missed out on yeah.

E

uh Let's see, then we've got uh yeah, so the ping is, I guess, getting an update. Some of that stuff has expired and come back and refreshed here and there, and then we have one list expired draft, the idr extensions.

E

I wish you were beer me too stig go ahead.

L

uh Yeah, so I have this mld draft that is not listed there, so um that was waiting for some pim extension to be done, but that's done now it's in all 48..

L

uh I did post an update before the meeting in march and sent an email. I believe I'm done with the document um and I sent an email a couple of weeks back as well. Yeah all right, but.

M

Anyway, as far.

L

As I know, it should be ready, but yeah, I'm hoping it can go to last call and get some more review actually and and yeah just expired, I'll resubmit it again. Today, yeah.

E

I

Theme yeah otto has been talk, poked promised you know, but they want to imagine the second one.

E

Second, one being.

E

Three in the queue there's two in the queue and one has chair commons outstanding. Would you be addressed by the authors so that the v3 extension.

I

Okay, nagendra promised.

E

This time in june, to push it up the hill, nothing happened, yeah.

I

E

Response from okay uh man apparently has the hendra's leash and we'll be dragging him back into this. Thank you. We have someone at the mic.

N

uh Just some words about that idr extension.

O

N

Neyman jeffrey drunk juniper.

O

I

N

So idr extension drafts, uh I talked to the main author and editor xiaohu xu before and he said he is no longer focused on this work, so we need some other co-authors in the draft. To pick up the remaining the editing work to address those comments.

E

Wow: okay, thanks jeffrey all right any comments close that piece of material.

E

What's the one sharing mode, I was told, sharing mode perfect, all right. First item beer, multicast service, jeffrey.

N

Hello, um so the beer, or markus as a service draft, was recently adopted. The working group documents um today, I'm going to talk about a new section that I added to the to the zero one version: um it's about the supporting beer in vpn and it's actually.

N

This came up as a one from one of the comments from fang hong during the working group adoption.

N

So this is supporting beer in vpn, not using beer for vpn next time. Please.

N

So the basically let's say you have your provider you're, providing vpn services and your vpn customers are running beer. What do you do? How do you support it next time.

N

So this involves both overlay, signaling and underlay work um customers bear signaling, um then they can do the igp bgp signaling in their own sites. But when it comes to over this provider core, we would use the bgp signaling the existing idr extensions for beer signaling.

N

I believe it can be used for vpn ip sapphire as well. So you just attach your beer information to the vpn, ips and rois, and then everything should should work for the overlay signaling part. Now it comes when it comes to underlay. How do you get the customer beer traffic across the provider network? There are two solutions here. One is that you just use ingress replication.

N

So when you do that, it's nothing different from regular beer at all. It's um now the your vr apps become the customers, beer or routers, and it's you just do the tunneling between the bfrs, nothing special at all. Now another option is that you forward customers beer traffic across the provider network using beer itself.

N

The reason to do that is that it gives you um efficient replication across provider core. um You don't have to do the ingress replication anymore. um The the one issue with that is that you to do that. You need to maintain the customer beer state uh in underlay, and that is what this presentation is about next slide. Please.

N

Before we talk about the underlay signaling and stage for the blvpn, let's review the general spear signaling and pift calculation in the non-vpn case, so the bfr's a signal, beer information, trvs attached to the beer prefixes and and for the egress router bf ir or bfer. They would include their bfr ids in the signaling bftr, which stands for beer, folding transit router. They don't include the bfr ids.

N

um So for each beer folding table there is a beef id. For example, it could be a beer label.

N

The beer gift id ranges are also included in the signaling, so a beef id basically identifies a bift for a particular subdomain comma set tuple.

N

Now how do we calculate that bift? um We basically for each fifth entry is corresponding to a bfer brs router. We find out how to reach that particular bfer.

N

We see that okay, through the unicast it's going to be going through a next hop, bfr neighbor and that neighbor advertise a particular label for this subdomain comma set. So then we put the entry in the bits and the key for that entry is the bfrd modulo, the p-string lens. The next top information for the entry is basically the beer label from their neighbor and a unix unique. Has four information on how to reach their neighbor notice that the bf er's prefix here is only used to find how to reach it.

N

But it's not used in the beer folding table in the beer folding table, it's just a bfr id next.

O

N

So now, coming back, how do we do peer review signalling in the underlay now in the provider's underlay? A beer sub domain is now extended to include the uh into a customer in that in the tubule. It's no longer just a subdomain of the provider spear domain it also you could have.

N

You will have a per customer subdomains. There notice that your different beer vpn customers, they could have overlapped, subdomain, ids or even bfr ids. So now we need to identify each beer folding table using using a uh additional piece of information. Here we call it. uh We use edit raw distinguisher in the control plane, um but in the uh for in the following plane.

N

It still just use the pixel id as before, like a beer label and the beer architecture initially intentionally made sure that beef id itself is just opaque number. It does not carry any other semantics and that design allow us to do this. Now you can extend the sub domain to includes uh customer information whatever, but when the folding plane, the b5d, is just opaque number that maps to whatever tuple you give it to give to it.

N

So that's a very good design that we are making use of now um now when it comes to um signaling now the pe routers and pe routers in the underlay, they will add it has beer information trv for their underlying loopbacks. Only and now inside the uh brt uh info trv they use they add raw distinguisher to the subdomain id and name for the pes.

N

They will include a beer proxy range sub glv to list bfr ids for customer bfers that are reachable through that pe.

N

That information is now used to calculate uh per customer or gifts.

J

Can I ask an understanding, question sure um I'm lost at the point. Oh tell a second um behind a uh in in the service provider domain. um Let's assume a situation egress pe with the two or three um egress ce of the customer. Each of the egress ce has has a bit in the bit string. um Is that mapped one to one into the the beer bit string in the core when you're right? When you do run it.

N

So for each for each customer biffs in the on the on on the ce side, then there will be corresponding um biffs in the in the provider network itself.

J

So it's a one-to-one mapping.

N

Yes, yeah, and I will talk about the scanning implementation on that as well. Yeah.

J

N

So this is a picture of the involved on overlay and underlay signaling.

N

We have those small clouds for customer beer domains using igp or bgp signaling. They connect to the pes and among those pes you probably cannot see the color clearly, but here the purple color is overly signaling among the pes using the idr extensions and then in underlay the peep.

N

There is a provider beer and we both the p routers and pe routers. They use igp or bgp signaling for for both provider domain beer and customer and customer beer domain. Signaling next slide.

N

So the existing drafts already talked about a provider providing beer transport to multiple clients which could be overlapping, but in that earlier version the assumption was that those clients, even though they are different customers they they would all be in the same global table and and the beer prefixes from the customers from the clients are actually advertised into the underlay.

N

That is changed that can can stay, but now with the vpn mechanism, and we can use the same mechanism for vpn used for both vpn and non-vpn cases. We basically instead of leaking the customer prefix into the uh into the uh underlay.

N

We are using the or just leaking the customer, bfr ids into the underlay, and that makes use of the gear proxy range subjects, and that is added in the into the zero zero one uh revision.

E

N

E

P

Huawei for the beer whipping- I think english replication is the best solution because, as you said, it has a low air state on the key motors to nick the client pfid range to provide a network is not a hierarchical solution. I think it somewhat violates the traditional weapon architecture, because either of the clan bfr, prefix, clan, afrid or client bfid range is the root information of the client network leaking them into provider network. This is a scalable problems.

P

In addition, I think you should check whether it is beyond the scope of the charter of the year working group and whether it is under the current beer architecture.

P

I think it is somewhat beyond what current beer working group can do. Thanks.

N

um I have some. I have one slide uh regarding the scaling considerations.

N

um If that should not be the last uh slide or or is it can you yeah yeah? So uh indeed, now um we have uh customer specific, specific information in the provider network.

N

Basically it's per customer or beer folding tables, and that is basically a trade-off between the efficient replication and additional states.

N

Now, as for the additional states, I want to point out today in the mvpn or evpn, when you do selective tunneling, you are essentially adding additional state in the provider network for corresponding the customer flows. um You for you, for example, you could have one p2mp tunnel for every customer flow uh in in the provider network.

N

That is the precedence and, of course, uh the provider has to make a choice to decide. Do am I going to use ingress replication or using the uh uh using the inclusive tunnel for all my customer traffic?

N

um Sometimes that's that may not work well, because, just because the the amount of uh additional replication and in you know, provider networks, that's not going to work out. It's not it's, not economical. um So here is the similar situation.

N

Yes, ingress replication among the vrfs will work, it does not have the states, but if you do the uh introduce additional customer gift state in the provider network, it provides a trade, uh efficient replication and you, as a provider, you can control.

N

How many uh uh customer base to be supported in your provider network is compromised, and my thinking is that if the multicast or beer demand picks up, this solution is acceptable and it's actually feasible and it's worthy. That's my view.

J

Thomas eckhardt again, I think the the key difference is not even starting from the number of states that you have, but how you can plan it right. It moves it from application created state which even the operator of the customer site may not be able to well control to um uh operator control right, so the number of bits are controlled by the customer operator, so that can be brought to be a no number. Obviously right. So that's that that's that's the main benefit. I think it's a lot more controllable.

N

um Here is the um the the provider can still has control right. So.

J

That's what I.

C

Meant in terms.

N

J

Don't you don't even need to argue about the numbers but about the plan.

A

J

The numbers you cannot plan, you know when applications are starting to uh to to create flows right.

E

Right this is great, but just to help clarify what toronto is trying to say: you're, comparing this to traditional ip multicast mvpn, where it's all flow-based state. It's all unbounded, it's driven by applications as opposed to the provider and.

J

You still have this date on the pe of the service provider when you're running traditional beer only in the service provider, you still have that state there now you're pushing it back to wherever the customer wants to have it and from the customer you're only getting a planable accountable, chargeable number of bits, kind of distributed via the bit string. So it's a totally different model. It's not kind of compare sizes. It's called, I think, yeah.

E

Like these are comments in support yeah, but it's from toronto.

J

Thank you determined, I mean see it's I mean he didn't bring them up in the first place, so they're. We need to work out a little bit better marketing of this, because obviously pushing out native ip multicast, so to speak from the pes would be a giant step forward. Thanks yeah.

I

And tony p, juniper is the first tourist marketing will warn theirs overseas.

I

Now I have a technical comment on the igp redistribution. So uh if we extend the beer information with the rd, uh then the computation is basically different. Primary key and um the whole igp will have to support it to work correctly, which can be done, um but what I suggest is to add to igp kind of a capability indication in the router description. So you know that you're dealing with people who can actually support this rd or otherwise, whatever you have it partitioned or you know you have to deal operationally with the issue. Yeah thanks.

N

Next slide yeah, I think that's probably the last one just try it next slide any more.

E

Questions comments.

E

We have one comment: oh sandy volunteered to take minutes. We already have it done all right. We got to handle sandy. Thank you, though, all right thanks, jeff friends, excellent next, our next is yours also, I think so here we go.

N

Okay, so uh this is a new draft uh from uh uh co-authors uh in juniper, zt, channel, mobile and nokia. Next slide.

N

It's actually a follow-up of two drafts and the presentation I did in lasa etf.

N

We had some discussions on the beer extension header, it's based on the mqs extension header drafts, and we strive for design and generic generic header extension mechanisms that is aligned with nqos and ipv6 extension header, so that we can support some generic functions with the same extension header and whether it is for mpos or br or ipv6, and we also strive for multi-vendor support of this proposal, and you will notice that we have pretty much major vendors in this draft except we're trying to still get cisco's support.

N

N

So there is a illustration of the header definition at the very top is original beer header it would have. Its protofield will have a value to say that the beer extension header follows, and at the beginning of that there is a header of extension header and then followed by the extension. Headers could be multiple of them next slide.

N

Now um the header of extension, headers, um the there is the first four bits: the reserve field. uh It's really just for it's a enable because this could be used for npos as well. We want to be able to see that don't treat this as an ip packet and next one is a counter of the extension header, followed by the extension header total lens, followed by the original upper layer protocol type. That's the real payload after extension.

N

Header, then, is the next hop type indicating the the real the type of the real next hub following this header of extension header. This value of this next hop field is from the internet protocol numbers registry.

N

Remember that we strive to use the same extension, header mechanism for all protocol layers, mpos, b or ipv6.

N

Therefore, we want to use this uh address the number space from the ip protocol numbers and that way, if there is a ip extension header for a function that can be applicable, uh can be applied to beer or mpos, we will just use reuse, the ipv6 extension header now, the the key, the the real that there are two main uh fields here are critical here, uh total um I shouldn't say uh critical, but it's important that total extension header lens gives you the ability to to directly locate where the payload is, for whatever reason, um without going through the headers one by one, the next hop header or value using the uh ip protocol.

N

Number space allows you to do the uh use, reuse, ipv6 extension, headers number of headers uh in this one. um I've heard from some people saying that you may not need that or you may not want there. I want it there, for example, if you have to remove a header- and you may need to uh update this field, why bother including it there? Just as long as you have the total lens? Each everything should work. Fine, that's um yeah! um We can discuss that with mpos the co-authors as well. Yeah.

H

N

Oh, I already talked about that. Why do we want this? One beer, header, protofield itself, is a six bits with its own space. Now we, when we use this one, we can reuse the uh ipv6 extension headers for whatever function. Now I do want to point out uh using the internet protocol number space does not mean that every time we design a new beer extension header, we have to allocate a number from that ipv6 uh registry. No, we only need one number.

N

That number will just means that the next header is a really extension header that is not about the ip it. It could be that this could be for mpos for vf or whatever. We only need one number from that registry.

N

um If, if, um if you know that you're dealing with a beer or encapsulation, you know that's, uh that would be beer specific. If you know, if you're doing the mpos, you know it's mpl specific next slide.

N

So now extension header, it's just like ipv6, we added one optional extension field there. uh Basically, let's say that we have to define five mpos appear: specific extension headers for beer functions. We get one number from ipv6 ip protocol number registry and then we can define.

N

uh uh We can allocate five extension and value for that field in in this picture and so that they can represent different functions uh with different beer extension headers. um We could also have one extension value assigned to indicate that um for this sphere extension header, there are multiple tlbs for different uh functions, so they could. There are different ways to do things. You can have one extension value for each spear, specific extension function or you can have one extension value to using different tlvs to encode different information for different functions.

N

N

So um seeking comments and suggestions, we try to try to reach consensus from major vendors and operators. um I mentioned that we already have quite some major vendors here. uh That draft song is uh draft itself is from huawei. So I assume uh well that that's the implication that implies that we we do want to work with all the mentors, including huawei, to to uh to support this.

E

Thanks any other comments or questions, no one in the queue all right great stuff, thanks chase.

A

E

Where'd, this come from.

E

Sandy awesome, yeah, okay, so we need to get sandy on the mic.

E

Sandy, can you hear us.

B

Yeah, I can't hear you, can you hear me.

E

I can hear you all right, you see the.

D

E

Yes, we got you all right, go ahead teddy. Thank you.

F

Okay: okay, thank you and hello. Everyone. I'm sandy zhang from zte. This presentation is bift id signaling for brte. We have calls our rioja.

E

Yeah, can you speak louder closer to mike, maybe.

F

If this is better hello,.

E

A little bit and we need more than that.

F

Okay, the steam slag. There is very loud echo.

E

Yeah, we only have one speaker in the room that seems to be uh yeah. Just do your best to go slow and loud.

F

Okay, if this is better hello,.

E

Yes, that's better hello, hello,.

F

F

Okay. Okay, thank you um should, I repeat the first page again: oh okay, let's move the uh this background. Okay from the brt architecture. We know that drt uses explicit passes to forward multicast packet in vr domain. The path can be calculated by the controller.

F

Every bit position of the bit string in a brt packet indicates one or more agencies instead of a bfer, as in beer brte in each bfr has no routing table, but only a brte forwarding table indexed by a set identifier bit operation and populated with only those agencies to which the bfr should replicate pex2, as described in brte architecture.

F

All the beer, encapsulation methods apply to brte such as nprs ethernet or br insects. Next, please.

F

The brt forwarding is achieved by the beer header too, but the composition of bit string and the forwarding table is different from beer. We know that the bift id is used to locate the forwarding table of the packet in order to distinguish the forwarding table used by brte.

F

The bift id in beer header needs to be different from beer. Next, please.

F

For the bift id signaling, let's take isis protocol as an example in order to support mpls internet and the bearing sex encapsulation, we advertise the mprs and non-fprs encapsulation sub-sub-to-v associated with brte in for sub-top, which is defined in draft itf brte is is, and the beer's ipv6 encapsulation sub sub sub trv can be advertised in case the node wants to use brin6 encapsulation instead of internet.

F

All the advertisements are similar with fc 8401 and the draft lsr mpls extension in case both of the mpos and the non-mpos encapsulation sub sub tovs are advertised by one node. The label in mpls, encapsulation sub sub to v, and the fifth id in non-ampus encapsulation sub-subtle v should not be overlapped.

F

The second only in ospf and ospf v3 is similar. So that's all any comments.

E

All right, let's come under the mic.

J

uh Tallest eckerd yeah- um sorry, I still haven't didn't, have the time to um come out to conclusion with this I'll I'll certainly be happy to support it from the r for from the um brte side. We, you know the uh soon to be rfc has is describing you know at least two high-level models of how to share the si and sd space with beer, and I think, depending on what we want to do there, that may have an impact on what we do in the signaling plane.

J

So I hope, hopefully we can have more productive discussion about that on the list.

N

Jeffrey from juniper, um so I had a comment uh for uh another draft from uh why more. I had the same comment applied here. um I saw a response from from primo, but I sorry I haven't got a chance to reply, but here my understanding is when it comes to brte.

N

We have two things to worry about a bit: one is the bf fifth id and the other one is the content of the dips.

N

In case of a regular beer, each bfr will calculate the contents of uh the fifths, but when it comes to brte my understanding that each bfr only needs to care about its local or the big positions for its local adjacencies, whether it's direct adjacency or router agencies, so, and that that information is better populated from a controller and instead of using igp to signal, and if you do use the controller to signal uh uh to pro to provision those uh content of the bits, then then the bit id itself can also be signaled as part of that provisioning instead of using ige signaling.

N

um As I mentioned, um I have not got a chance to further discussion with my mom, but I think this is. uh This is related to the discussion as well.

E

This is great just for clarification, you're talking about assigning the bits from the controller.

N

Assigning the bits uh yes uh well so assigning the bits uh is a part of a planning process, and then how do you get the space to the router and it's in the old days? You may you, for example, in the old days you allo you assign a loopback address, and then you write down a piece of paper and include the router and enter it here is similar. You assign the bits and then you you need to put it into the router, how to put it in the router.

N

Nowadays you can use the controller or something once you do that, then you you uh as part of that as a provisioning, you, you could use uh to do the big signal uh to assign the fifth ids as well thanks.

A

E

F

Okay, um we know that there is a working group document about jabir t, young and and in that draft the the ftid or the agency's bp can also be assigned by the controller and can be downloaded to the devices to run for it. So um so, if we do this work or by controller, the brt young is enough to do this work in case. We want to use igp for signaling the bit operation of agencies.

F

Maybe we also needed to advertise the gift id for the working table. Looking up yeah.

E

Any more comments.

E

Looks like we'll have an active discussion on this on the list, some good feedback. uh Thank you sandy.

E

All right. That is the end of our agenda.

E

I would call this by far the quickest beer working group meeting- we've had um probably the least animated we've had if we went like yes, even though we started a good point. Actually, if I even docked that time off we're about 45 minutes, then of actual operator operation here, uh normally we're pushing our two hour window and people are chasing us out the room. So at giving the point give some okay, we have an a.d who's going to give us some wisdom.

G

I've actually just been there's been a bit of discussion on the iesg and I have been thought that we would remind people just while you're in the meetings, if you're not at the mic. Please wear your masks. We there are people testing, positive, that aren't wearing masks and the masks are mandatory. So I just needed to please say if you're in the session and you're not at the microphone talking, please wear the masks, but other than that.

G

I'm yeah, I'm the new 80 and I'm here to help as much as possible and we'll do what I can and if anybody needs anything, I'm I'm around.

E

Thank you andrew. Let's make sure this is not a super spreader event.

E

Oh one more, my question go.

M

Ahead, yeah: well, it's not a question. It's a comment. Being nokia should be in the next ietf uh come up with some beer success stories. uh I don't know whether that's part of the itf or not, but just you know, show some of the deployments for.

E

C

E

But he's here so isn't there some work in i2, where uh european i2 they've got some p4 implementations of beer and they're doing some actual live testing now.

Q

uh Yeah there's um uh they presented it at mbondi last meeting or the one before um it's one of it's, the french uh and ran uh renator.

Q

Oh yeah, they have a network called rare net uh and it is a network of uh tofino switches, um p4 switches that they implemented beer on and it is a beer network. um It's a global network, rna network that includes that that does have beer running and they added an amt relay and a unicast multicast translator. So um so yeah uh come to mbondi um or check out.

Q

um We would love to you know, uh there's there's a mailing list that talks about this deployment, but it's a pretty neat uh deployment and it's it's exciting because it um it has the confluence of both beer and amt, which is kind of a interesting. You know very promising mix um so yeah, that's a that's a cool network to take a look at.

E

Can you send me the links or send them to the list and then yeah.

Q

Sure, okay, definitely, if I don't, I forgot so just remind me, yeah.

E

Q

I I can also add that, uh since, since you asked greg, um we are or um we'd love to have in mbondi um your other working group. Don't forget about us. um If there are um operational, where are we with beer? Do you are we ready for operational considerations and are we ready for um ops documents and drafts in mbondi pertaining to beer, because I think that would you know if we're at that point now? We very much welcome that in bundy.

E

Thank you lenny for off the cuff. There appreciate it next.

N

Jeffrey from juniper, so as a multicast engineer, I've always said the beer is the best mouse multicast technology I have since, um but this deployment has been kind of disappointing, mainly because it's new encapsulation new forwarding algorithm and therefore you neither need a programmable chips or you need brand new chips, and that gives us a chicken egg problem.

N

There have been many customers who wanted to do beer. They talked to us to many vendors and they said. Oh, you cannot do this yet, oh you cannot do this on all platforms. Therefore they back off when they back off the vendors. Also back up, they say: oh no, not many customers wanted. So this kind of chicken and egg problem is what prevents white deployment.

N

But um prime pioneer vendors and pioneer operators will break the chicken negative active dilemma, and I am optimistic that it will happen and in the near future,.

E

Thanks jeffrey.

J

No, no sorry, I have a lot of back pain. I can't stand a lot. um What was it three points so the first one just to retaliate on your great um recommendation, the beginning for for chairs me um for the people in the room. Please make sure that you are locked in at least once into meet echo, because that's how you're getting counted right. So you want to know that for the room size next time um and uh sorry, it was too late for this meeting here. But uh that's so there is the on-site tool.

J

We should all use this for the microphone line. I never understood it. I don't think we need it for the microphone line, but kind of for counting how many people are in in the room and and the proceedings. I think that's that's very useful because we don't have blue sheets um taurus for some clarity.

E

I'm logged in here at the laptop that counts me as well, though I don't have to I.

J

Hope so, yes, yeah, okay,.

E

But for those who aren't in media echo, they can just use the scan and then get on the blue projector.

J

Or you just use the tool whatever I haven't figured out, I need to ask the the tooling people how they in the proceeding, actually you know, count the stuff, but if, if you're not on any online tool, they can't count. You yeah.

E

Yeah, it's all done automated now, yeah exactly.

J

E

Sheets are no longer blue.

J

Right um there was something in the middle. I forgot okay, uh h and then um yeah I mean hope. You don't find this offensive, but really you know come positively mood it to the msr six path right and consider that you know this.

J

This whole technology, maybe can can use another even more, maybe researchy and and longer term solution, because one of the things we specifically haven't achieved is getting really into host stacks, and I think that, just by taking the word ipv6 on on it and making native v6, we we may have to get it better.

E

Let's not have the discussion here because encapsulation doesn't dictate.

J

Hosts, oh no, all I'm saying is just just just come with a positive attitude right. Let's, let's not, you know, dwell on tasks yeah. I think thanks thanks.

R

Greg mursky erickson. um I really appreciate the ask for um more uh ops, related information and I think that that's what oem is for. So it's basically using us our alphabet soup, it's a operation, administration maintenance.

R

So I'm part of this effort and as chairs noted working on being document and ping document, then enable us to progress, mtu discovery and bfd documents.

R

So I hope that will be a good addition to the ops related suite.

E

Excellent. Thank you, one more yeah uh who.

M

My big goal in nokia um just to comment on the chicken and egg issue. I do agree on that, but I guess there's a lot of great work in this working group. There's a lot of drafts that are trying to address different parts of the beer technology, but for the providers well, not providers for the main companies that are implementing beer.

M

I would imagine that we want to concentrate on a set of functionality that we can interrupt very nicely with each other and get this thing going right because, as you said, we need like, let's be honest here- we need the deployments to start putting more technology into our routers.

M

If we don't have the deployments, you know there are other uh higher priority stuff that you know, companies will start working on. So that's all I'm trying to point out is that maybe you know in the next meeting we can talk about some of the main pieces of beer work that we need to implement on all uh these companies. You know the tier one companies that that we are so we can get this thing up and deployed in the customer side a little bit more again.

M

I don't know whether this is itf or this is offline conversation. That's the part, I'm kind of wondering you know how we can tackle that.

J

Just a quick reply- um and maybe you know I told the secret again, um maybe looking into what what we all came here for service provider and the wide area. Isn't the only you know thing we can attack right, so data centers, we've seen michael menth and and companies. You know p4 implementation, so data center may be more ripe, even though we may not be the ones that have the best connections there, but maybe just talking to the right people right.

E

And uh j2 broadcom has support. Now that's a huge step.

K

Okay, it's vancouver from deutsche telekom, uh so from the network operator side, um the chicken and egg problem which have been from mentioned from jeffrey and human, and also the operations management side mentioned from greg, are very relevant to us because for us it's always the question. How interoperable is is this stuff? Because it's not a secret? We are not on a single vendor strategy um so that point one is very important, but the other point as well is um that we are getting challenged internally, also a lot, how many others of our.

K

Of other telcos are using it, are they using it in the backbone, or is that a data center technology, because this determines for for us? Also, how mature is the technology to use, um or are we the first one or are we the only one demanding it, because this has also, obviously, in the long run implications on how well is it maintained? How well is it tested?

K

How well is it developed further for on for upcoming feature, sets so having somewhere a source other than personal contacts, to get a grasp of how many providers are interested and how many providers are using it and for which cases would be really beneficial? Also for me and my arguments to use it internally to develop it further and yeah to to give it also some more um relevance in order, in contrast of implementation, excellent.

E

So if I can just wrap this up with my experience in this as well, I haven't spoken to a single vendor who looked at this and said: oh, I don't like it it's always. When can I get it? What platform is it on? You know how many platforms support it, but then you get to that. Who else is doing it? There's that coward state right which I understand, but this is forwarding plane. This is just not another routing protocol. This is the forwarding plane. So it's the narrow part of the hourglass is the big challenge.

E

It's new hardware, and just to your point, jeffrey too. Not all programmable chips give you that option, because it requires header manipulation, post replication, if there's not a pipeline to do that, you have no programmable path to do it. So even programmable chips aren't necessarily ready for this, so it it's it's a heavy lift.

E

um Even if the implementation is simple, it's still more bits.

G

So I also just wanted to add that you know, as as taking off my 80 hat and speaking as an operator.

G

One of the things we've been working on internally are certain routing devices, etc that are more tailored for the african market, size-wise, etc, and we are working to implement a lot of the stuff in our stuff in our products as well excited.

E

Wait: tauros has another comment: yeah.

J

On on on your rant, um just just going back, you know, original multicast was also pushed in the market by software implementations right. So that's the question: what is the strategies that we that we, you know, find marketplaces where that happens? And then you know the big elephants are getting moved last right. So that's that's always been the problem when we primarily selling from you know. The big elephant devices with with expensive hardware need to want to make a jump start for a new technology.

E

All right, oh, we have one more mic approach, david.

O

Lampotter, so there is also chicken and egg with software implementations. um Speaking as someone who would do one of the software implementations, we are stuck because the use cases from data centers and telcos in this, and they want the hardware implementations and they don't see the point of start with the software implementations and there's like yeah.

J

So there is a joint session from babel, monet and roll on um which with which are looking into multicast, and so you know, we've tried already to to discuss uh beer type, beer itself or beer type technologies with role, and then we just didn't have the time and critical mass and so on. So maybe we can get more critical mass into that. You know software space because I think there are a lot of use cases uh all around but yeah. Obviously, people haven't worked enough.

J

These people here are mostly paid for by big boxes so for big service providers, so we'll need to expand the community. Not me.

G

E

Right, I am an independent contributor all right, any other questions. Comments. Gripes fruit, veggies is that we got one more. We got one more.

H

Hi, this is uh ron enfeld, the chair of the uh monet working group and the session that uh just mentioned this on friday morning, first session, okay, friday and uh yeah. My question is indeed, these are mostly software-based routing solutions that we're looking at there and would be or be applicable.

C

H

At least sandy is giving a presentation on how to uh to carry uh uh beer information in the label product, but how this works on the boarding plane is not yet clear. So I have to find that out before friday,.

E

We're on it all right once twice. Thank you. So much have a great week, hello,.

A

E

A

E

Hello, yes, hello,.

F

Yes, I just want to add some discussion for for for the, because in china we had talked beer technology to operators years again years ago. So I think that in china many operators know that beer is a very good technology and they want to use it, but the another driven for the beer deployment is that how to use it for the application. So we just uh we had talked the vr technology with the cdn and cdn content delivery so and some media uh delivery uh application to work with it.

F

So I think that, maybe later um there can be used in china uh not very long yeah, okay,.

E

Thank you sandy all right. Everybody. uh Congratulations! You've already signed the blue sheets magic. Thank you very much have a great week masks on.

K

Is you know, 10-12 minutes to support good thing? We had a short agenda.

E

Ice ice is a hedge down.

L

What's that isis stuff here.

E

No, no he's he actually jumped on the list like a month or so ago and had some input.

E

I was kind of surprised because he's pretty busy, but I think from what I understand they may be coming out with some info like this summer, so yeah we might hear what they're doing I mean it's pretty clear as nasty land play, knowing the players but uh yeah. What structure were we're really doing we'll find out.

A

E

All right yeah this is this- has been fun. You know it's been uh two years of remote, I'm just kind of doing my own thing for a. I remember this last night talking to smart people. You know talking about heart. Problems like this is fun.

E

I enjoy what I'm doing in my own time as well, but uh I need my head challenged. Yeah, don't get that done too much by just building someone's afternoon.

E

You got lunch plans.

D

C

How are you doing good? How are you I'm not too bad.

Q

Q

About two and a half hours without traffic, so it's a nice little short drive and I grew up around here. So it's good to get back. My parents are 20 minutes away in jersey. So, okay, yes, yes,.

Q

um I can tell you, restaurants and wine yeah, you know, I don't know about beer yeah, that's you know, I'm not.

K

Q

Fan of american beer, so I I can't give you good advice.

E

It's because you're living on old knowledge, very.

L