Internet Engineering Task Force 111, 26 Jul 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF111-BIER-20210726-2300

Description

BIER meeting session at IETF111
2021/07/26 2300

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

A

Sandy, even on.

B

Yep she's there, okay, uh actually.

A

There we go got it from straight okay status, it looks like tony's, audio is coming and.

A

B

B

There you go wow, that's weird.

B

So I'm going to try to present this way and see how this flies. uh The presentation view doesn't help me. um Is there a share because presentations in line show of hands start.

B

Share screen, share, pre-loaded slides, it says yeah, no slides available because nothing's there weird didn't like that's too bad, because last time it worked really well. It was great that would just go to the uh data tracker of all the uploaded slides and the presenters could grab them themselves from that link and go so we went backwards this time around. Sorry, I'm not certain, what's broken with it, probably because they they bounce us around location-wise, I'm guessing, uh but I'm still figuring out how to share something here. Is there.

C

A meeting by participant here in the working group who want to step forward and be helpful.

B

Don't sound like it.

C

You know that just that they're not shy, but maybe it's really a bug because.

D

The the meeting got moved. That's what I was thinking uh that that seems the most logical uh conclusion.

B

But quit that all right, so I'm down to just this crap too.

B

That's there there's my.

B

B

That's the deck it's there. I think I'm done so. Let's see if I can share this thing old-fashioned way,.

B

Before it goes fractal on us there we go. Can you see that.

A

B

Okay, if I probably go.

B

Full screen, or just do this- that's the safest way to do it all right now the trouble is tony. I can't when I go full screen to show these slides. I can't see the meet echo interface at all. I'm totally blocked out, so I'm gonna need someone you and sandy to manage all the questions.

B

Unless now that, okay, this is just with my slide deck, um I've got the other ones queued up. If I have to run them this way, but hopefully the others can grab theirs and share their screen, and it won't be so crazy.

B

Also, the video link, I'm looking to grab that thing again and I can't seem to have, because we have one presentation: it's going to be pre-loaded correct, come on there.

E

B

That's always a great effect. uh All right, I just got.

B

A

A

When it died I'll quit that and where'd that let go under this.

B

hmm It's bizarre, okay, um it's I'm not certain what that link is doing. Let me grab it somewhere.

B

B

It's probably loading, I'm guessing all right that was down the queue yeah, so loading all right, cool um back to this freak show and.

B

Bam no wrong one that one all right welcome to beer uh thanks for the your patience on this one. This is uh unfortunately, a little snafu hadn't seen before this worked really well last time with integrated with our docs. Not now um you don't need to sign blue sheets. It happens automatically now, which is pretty uncool uh no. Well, please note. I don't think this has changed in a little bit but still uh understand what the rules here at the ietf for proper behavior.

B

I need someone to take minutes. Please focus on questions uh the mic stuff. That's not being um you know in the presentation itself and of course all this will be recorded. So we can. uh We can score you on how well you kept minutes um any hands. Anyone tony! Can you manage the hands?

B

I'm I'm putting a big order on someone who's at midnight or 1am right now, but this is broken. So I need an assist with hands.

B

Tony tony anyone else hear me.

F

Any volunteers.

B

All right, I hear you guys your volume up a bit, though it's really bad. I don't that's me or considering how much I've got going on here there we go that video works. It's loading up, cool, all right, um work on that docs update. So we have a list of drafts here that are in isg right now. They some of these got moved quite a while ago, but uh uh feedback immediately was the isg q was ginormous.

B

So that's all right! We've done our bit and we're moving on wait for some feedback. So moving to those who are in last call, uh we've got ls mld waiting for a shepherd, so this is going back again. We've got four drafts here that actively do or will be needing shepherds.

B

Please jump to the list I'll call each of these out again at the list after the meeting, so we can start making progress and, uh as you've heard me say before it's a great way to jump in. If you haven't authored, if you haven't, contributed you're looking for a way to get your hands in how the process works, this is a perfect way to jump in through it.

B

It's actually fairly simple, there's just a list of q, a that you go through to ensure that each of the you know check boxes have been done for each of the drafts before it moves on to the isgq.

B

I will take these lists and please please respond. Here's some they're, actually pretty clear, working towards uh working group last call, or even there again, here's three more shepherds so we're at seven now and we got some old stuff. We got stuff. That's expired! um Quite a few actually- and I don't know if these are coming back or not. uh If you're authors of these- and you feel that you want to keep pushing this forward, let's jump back refresh and bring them back to the list.

B

Otherwise they will die and rot into the history of the ietf.

B

All right so again, these are expired, but we've got people working on updates. Some are complete. One here is completely dead, just continued from the list before actually so same game. If these are things we want to uh as authors, you want to see move forward, there's been good response to list yet and there's just been a timing, thing feel free to refresh bring them back to the list and we can start moving on these.

B

Now the big work in process- 8279 we've got a good list of volunteers, nothing's been produced for them, and yet I imagine there'll be an interim being scheduled. I believe, sandy's taken the lead in this, which is fantastic, so um sandy you know, feel free, pull an interm and trim together on this either with the focus design team. If you need to and go at it, um we're anxious to see some some progress in this group.

B

Two new drafts, I think, uh are these being presented, I'm not certain sorry and then the fr. So it's been merged. um There was a request from the chairs and at the list to actually have this have a section that talked about how beer operates in conjunction with the igp.

B

That didn't happen in the merge and there was some hand waving is why it didn't happen. But, honestly, we need to listen to the group. We need to listen to feedback. You don't march forward on these things alone. This is why we fall into pits in the past. We've had working documents in the past where they refused to listen to the group since rev0 and no progress was made, so these things are important. We see this not just from the chair.

B

This came from other participants that, in order to gain context of what you're trying to do with frr having a section, a dedicated section that talks specifically about how it operates in conjunction with the igp, so then we have context to understand how this is modifications to implementations, to allow for operating with different control plane. Then here we go. This is a great way to do this in architecture, for the document doesn't change your content, any it just helps the document fit the frame of the way people think when they're reading this stuff.

B

So please um consider that bring it forward. The author list is also gigantic as well too, and that needs to be pared down, as it was confirmed by the a.d, that's kind of the history of the ietf. We don't push documents forward with gigantic lists.

B

Okay and here's our agenda a lot of stuff uh before we got there anything jumping out anything missing anything. We need to change anyone not here needs to cover.

B

Any hands tony, I can't see hands hand his hand.

B

Now, what do we do? There's a hand, hand.

C

Yep now so, with with respect to you, know, taking feedback into account, so what I've seen what actually works in the people using it is that you know the github are great, are as issue trackers right. You can bring up your issue in there, uh whether your chair or somebody else, and then you can go back and remember these things. uh um That's the best thing about github, all the other stuff is crap, but uh you know we don't have sorry, we don't have a comparable tool.

C

So if, if something like that fr or whichever draft you you're thinking of you know, needs more communication, I think it's better structure than these. You know mailing lists that, where it's really hard to find stuff after a while thanks.

B

Absolutely actually you uh you outlined that really well, on the request for uh volunteers, for the uh rev of the architecture rfc, that was fantastic. I appreciate it. We know their hand.

G

Hey greg, uh I've got her thunder rod so um to what tortola said. uh I don't have any problem with the working group using github for specific drafts or in general.

G

However, um I need you guys to agree on how it's going to be used. Meaning is everyone going to go to github? Is it only going to be used to track issues? How are the discussions going to be made?

G

um You know normally we configure or reconfirm stuff on the list, some working groups, if you look at quick, for example, everything was pretty much done on github and that's fine. We just need to make sure that there is um your clarity and that anyone that is following the the mailing list knows what to do right uh and it's not lost it. Just doesn't see any discussion.

G

um There are a couple of rfcs that were produced by a working group that was formed to do github stuff I'll forward them to you guys. So you can take a look and there is an ietf organization github. So we can put the repository for beer in there. If that's what we want to do just so, you know, I think, if you go this way, you would be probably the first working group in routing to officially use github.

G

I mean people use it all the time for their individual drafts not to track working group comments and things like that up until now, so um you know others will be looking at you guys on. You know, to learn and to get best practices later so I'll. Send that to you guys so.

B

You said you said quicks doing everything up there is there any group, that's doing like just individual draft done through the whole process, not just the authoring, but the feedback and tracking all the way through publish.

G

B

Instead of total.

G

Yes, there are many working groups that are doing that and um I think https is doing some of that where some of the draft work is done on github and others somewhere else. The point is that uh we need the working group to agree on how we're gonna work. Is it everything? Is it only a piece? Is it you know whatever it is, um I'm obviously fine with it.

G

uh It's just a matter that uh you, everyone needs to know, and uh everyone needs to um you understand where and how everything is and how to interact and uh how to do discussions and everything else. So again, some of this is detailed in the rfcs I'm going to forward you guys great so.

B

um Just as a possibility going forward, if we wanted to try this, I mean it seems like a whole lot to bite off to say: oh everything's moving there and people haven't figured out what that means. Yet, uh and even if we did that say, the chairs were prepped and we did it getting. The group moved over from paying attention to the list to pay attention to github is not a simple task seems to me would be tackle something that we do on github and we get the feedback and listen to how it worked.

B

If we liked it and if it was easier and on and on and then we can decide, you know we start moving things over that way. So.

D

That sounds like a really good idea.

C

Yeah, I I mean what I was saying yeah, so I wasn't. I wasn't referring to the official um process of the itf with github I, as a working group chair, I've also haven't gotten around to to figure out how much overhead it is. But you know many contributors have been doing github for their documents forever. So it's very easy to duplicate. You know comments and issues. You know on the mailing list and put them into the github, and then these authors are a lot more responsive to the issues.

C

That's a very lightweight approach and that's what I would recommend. As far as what alvaro is saying about all the official stuff in the iitf, I don't have opinions yet on that, but need to get them.

B

All right, tony.

B

B

Tony he had his hand up. Oh I gave up on him. I'm sue! Oh he's back tony. Where are you.

B

No, not certain, I don't know if his audio is messed or what he was kind of muddling before um so first item on the agenda, thanks, actually both you for that feedback, that's that's a great way to track stuff. I agree. Twitter sorting, stuff through the list has just been uh arduous and after two decades of this, it's insane trying to go back, and I said what when um so, first on the list is torless with fr.

B

Excuse me with the te arc is: do you want to watch the video or do you have a presentation? First taurus.

B

That would be great. So how is this shared? Sorry, I'm just upper left hand corner. You see your name under beer and then the list of icons there, the one that looks like a screen say share screen, should have a slash through it once you click it. The slash goes away and we see torlas's face.

C

Yeah, but uh how about my my screen is that shared.

B

Can you do share screen upper left corner.

C

B

Oh, it's giving me grant screen there. It goes yes.

C

Send me a request right window, and I want to do- is that the beer one and share and there we go and ctrl alt f full.

D

C

Is this? uh Is there sharing? It sounds like there is an audio feedback that it's sharing? Okay, so um I what is this slide saying? Oh yeah, so this was reported only at uh the you know, non-iitf 107 interim. Since then not- and this slide says uh you know, time flies when you're having fun with corona, but everybody was very busy.

C

So I have four slides of what hopefully are the technically interesting aspects of the textual improvements between 09 and 10, which is alvaro's responsible, ad review. You could also call it an iowa class broadside against the textual in quality of the document, which hopefully is now fixed and so yeah, so they were a really good recommendation for the restructuring. So there are a lot fewer high level.

C

Sections there there is everything that is related to the controller is really informational, because obviously we were not specifying the controller protocols and yang and all that stuff here. So that's one big section and then the rest of the stuff was resorted to fit this um and uh they're. Also uh what they're saying yeah um things like um you know: better comparison um with with beer um like, for example, birt, which is related in beer for, for you know how the routing information gets into the forwarding table.

C

That's also optionally, in brte, because if we don't have local routing local control plane aspects, we don't need that. So those things are there um a lot of terminology matching uh with 8279, so the beer layer is now described as constituting of the beer forwarding, plane and the beer. Sorry brte, forwarding, plane and brt control plane.

C

um The brt controller is not the only part of the brte control plane, but just called the reference model for the control plane, because you know any other implementation option would be a lot more explanation, so it makes it really easy. um Also, fancy thing the do not reset bit was changed to do not clear, because I somehow have been always using how to set a bit to zero as reset and 8279 was calling it clear.

C

So I'm, of course, now also using clear, I think that's a lot more clear terminology so um and uh yeah. So there was a one section that alvaro wanted to have for topology discovery and creation right. So there are a couple of different things: the itf has to discover topologies in a controller bgpls.

C

There is a yang model from from alex and there are other options listed and then, of course, the creation as a function of the controller, taking the physical, topology and figuring out, which you know adjacencies to create a bits for um so that's better described now.

C

The the question from alvaro, which was very weakly answered in 09, was how to distinguish in forwarding beer and beer to e, and it really is a matter of distinguishing. You know what bift to use for for a particular packet, um and that really is something which also in the beer architecture, wasn't really very uh clearly.

C

You know described because 8296, of course came after aft 8279, um and uh so there is the bift id field, um and uh you know you, you simply need to indicate if you're, just using the whatever bift id in in a beer packet, you just need to you know, have some configuration that says whether that's beer or brte logic, so so that you know what the semantic of the bits is.

C

um And then the question is whether that bift id needs to be derived from a combination of bsl sd and si, which is what 8279 originally says, but obviously in mpls forwarding. This is derived from the control plane. So if you don't use, for example, the igp signaling that you use for beer, if you don't use that for the br te um bift ids, then obviously you can simply.

C

You know assign any free, bift ids for for brte and if you look into the non-mpls encapsulations, for which there is a draft from from ice and others, it has multiple options.

C

Ultimately, this is something which I wish would be easier to explain, but in the end there is a lot of flexibility there and the maybe the simple operational recommendation is to say: try to map everything from bift back to bsl, sd, comma and si and then have disjoined sd spaces for beer and beer tea. Some sds are beer. Some sds are brte.

C

There may be reasons against it, so there is a lot more text about these different deployment options when you have both beer and beer tea in a deployment. So any feedback on that. Obviously more than welcome number three.

C

um So the explanation of the two pseudo codes and why they're two? Hopefully a lot better explained, and it's all about the reuse of the fbm from the beer forwarding plane. So the first pedo code is with the use of the fbm and the second code pseudocode eliminates that- and this also goes back into what is required. Brt forwarding and what's not, and so what I made as required, is what can be implemented with the fbm semantic and the things that are recommended should or may cannot be done with the fbm.

C

So you need to basically have forwarding code that is, is optimized for brte and that, hopefully, is now a lot clearer. So the fbm is is kind of this. Intelligent thing to um you know, track uh the bits and and reset them, and the logic of that can be changed for norm for the the mandatory brte simply one line of code different, but uh when, once you get into some of the um things like the dnc flag, the do not reset flag or sorry do not clear flak as it is correctly now.

C

um uh You basically don't need the fbm, it's actually saving right. The fbm is, uh you know another bit string length entry for every um for every bit, so the bift becomes more compact in brte than in beer. If you don't need the fbm- and it's really just you know for brt, it's it's overhead and so can be implemented more efficiently.

C

So and I think we're on the last one. So yeah.

H

C

More ascii pictures in several sections where alvaro was asking for it and then the fun part security considerations. So I was following everything pretty much that alvaro was asking for when it came to the security section he said well, there needs to be more text so as to not attract too much attention from security, folks and well.

C

What's the biggest difference is the controller, so there must be all type of problems with a controller, and so me, as an author, acting as a public defender for brte um and having had some, you know, background in the security stuff from other recent work that I've been doing.

C

I did exactly the opposite, which is you know, trying to explain how you know using a controller is so much more secure than using an igp, because there is a lot of history in the itf not having it done good job on securing an igp, and that has nothing to do with beer.

C

Just that the you know, standard model of 8279, of course, is to rely on the aigp and we've done all these things, and you know how good is an igp uh secured, and if you get access to the network and inject wrong igp information, you bring down the whole network, whereas if you have a controller, you know you attack one node, you can't attack the control plane of the other nodes right and controller interaction, uses tls, often very good secured. So um you know highlighting how much better it is because of the controller.

C

um The misconfiguration, I'm not even sure if misconfigurations are a valid topic for the security section, but I was elaborating on what the biggest misconfiguration issue is and that's around looping packets, which is why beer and brte have a strong, clear bit rules in the forwarding um and in beer. The weakness, of course, is the igp micro loops again is the the bloody igp with uh that needs then to go to ttl expiry, and we only have an equivalent case in brt with a dnc flag.

C

As long as we don't have dnc actually brte has less looping issues than beer, because it doesn't have that micro loop issue, because every bit is already cleared by the forwarding rules when it passes through through a node and yeah, then also the fact that a lot of the candidate deployments I can see for brte is not necessarily the service provider space where we started the beer from, but also with the interactions with roll and others. um You know industrial embedded environments and so not having a dynamic control plane at all.

C

But you know provisioning everything up front having static, uh you know, um bift tables, for you know, live, live forwarding or so gives a couple of really interesting deployment models which take a lot of security from the control plane out of the picture. So that was basically the security section. Maybe an interesting read for you folks and that's it.

C

F

Ac go ahead.

H

Of the vrte controller.

C

I only heard of the brt controller. I think you got lost at the beginning. Can you please repeat.

H

Implementations of the of uh of a beer uh te controller implementations.

C

No, I'm not aware of any and uh brt controller, of course, is a uh a word to saying you know that could be a person that is, you know configuring cli right, it doesn't have to be. You know explicit automated software.

B

There is, however, an implemented automated controller for beer that was put together some time ago, and I believe it is on on github. Making those extensions for te probably would not be a big.

F

G

So I just want to say that um the slides make it look like. There were a lot of changes and I think the changes were significant, but most of them were clarifications and storeless said you're, explaining a little bit better. Some of the things I did start the ietf last call because of that, but there's a difference of about 10 pages between nine and ten.

G

So it would be great if some of you guys took a look to make sure that we're not missing anything obvious uh there's at least another week and a half or so of the itf last call left. So please go take a look.

C

Yeah, I also sent an email to their extend. Please provide feedback to the teas working group, which had a completely full agenda, so I couldn't present to them, but I did go to them several its back when when we started this effort because they would probably be the you know- control plane, experts on things that they're interested in so maybe we'll also get reviews from them.

F

uh On the side no told us, I would appreciate if you have a good look at the yang model, because I reviewed the yank model a couple of times, and I was especially pointing out that it should have enough flexibility. You know right elements to support something like brt and the controller programming, all the bits, but it will be good. If you know from the brt side, you took a very close look, whether they we have enough of that in.

C

The end mode thanks, so I left the discussion uh with the feedback I gave on the yang model for beer. I hadn't looked specifically into the brte yang model yet because I think the thing I would first like to see is that we have a good representation of the bift in the common beer yang model, I'm not sure if an update was done on that. um So that's what I would like to get back and discuss next.

F

Yeah, I think the discussion was hung where the wish actually should split the yang model around along the brte or try to keep it together. Both the beer and the beer tea.

C

Okay- and I think that discussion to me would be coming after having discussed how to put bift information into the beer yang model, which I think the last version I saw three four weeks back, wasn't in there.

F

Yeah, it was too weak to be writable yeah, okay,.

F

B

All right, so, what's the intent of the video.

D

I

You mean the next point.

B

Oh fast forward, I'm sorry I'm completely.

I

B

I thought that was a te video. I'm clarified. Now. Sorry, oh! No! Let's move on michael! That's right! That's why michael sent me the link goodness I got tor-less in the mind, thanks norlis, as always entertaining.

B

So, um michael, is he there he's not here and we're going to run the video? Instead, we.

C

B

B

No, no I'm here, can you.

J

B

Oh, I hear you now yeah, I was scrolling down and you popped to the top great.

I

Yeah we prepared a video to have all the things together and I think the video is nicer than a live presentation from our side.

B

So run run the video instead of following slides.

I

Exactly exactly.

B

Okay, I'll run them from here. I believe it's loaded, um it'll be a quick fractal freak show until I change screen so bear with.

B

B

Okay, I just paused it just to make sure you guys can hear that. Can you hear that.

I

I couldn't hear that.

B

You could not hear the video all right, that's a problem so what's happening, the video plays out of my speaker, but it has to be picked up by the mic in order to to be sent back out um wow, because all it does is give me share screen not share app yeah. It doesn't. Let me do that I'll play a bit more, but um I'll let it play. While I switch back.

B

B

Can you hear any of that.

J

B

All right we got to find out michael looks like we have to go through the slides. Then you, okay with that.

I

uh Stefan is here, and uh he give he can give the talk.

B

Excellent, okay, do you do you have the slides.

E

To share uh yes, um I tested because my microphone does not mute the video as far as I see so, maybe I could try to share it.

B

Go for it yeah if you can try to do that, go for it go for it. Okay, uh screen granted.

A

E

E

So a short test, if you can hear it hello, everybody, my name is stephan lindner, I'm part of the chef committee. I think you could hear it right.

I

E

Okay, perfect, then I can start the video.

E

Hello, everybody, my name is steph miltner. I am part of the chair of communication networks at the university of tubingen. Today I will present the latest update of draft champion. First, we wrote it is the merge of the previous version of the draft, with draft mailing be a faster route that presented terminal based via fast euros.

E

The presentation is completely revised and concepts are generalized.

E

The updated version of the draft introduces an architecture for bfs view route, which I will present today. Further. The draft introduces operation modes that consist of protection levels and backup strategies.

E

In the proposed b of europe architecture b, file neighbors are connected in two different ways: either through a direct connection. That means directly over the link layer or via an indirect connection, for example, through a tunnel of the rokinon delay.

E

Further, we define three different forwarding actions for for three rod. The forwarding action plane corresponds to the default forwarding beer with direct connection. This means that a beer packet is sent to a directly connected bionator.

E

The forwarding action tunnel encapsulates the beer package with the tunnel header towards and not directly connected with, our neighbor. This corresponds to the default forwarding beer with indirect connections, for example, with the help of an ip tunnel.

E

The forwarding action explicits forwards the packet of an explicit path to a beef, our neighbor. This may be done through second routing or other technologies.

E

The explicit path must be given a backup forwarding entry consists of a backup fbm, a backup bfr enable a backup forwarding action, which is either plane tunnel or explicit, and a backup entry active flag. That indicates if a backup entry is active.

E

The backup fbm for a specific beef er indicates all these ers that share the primary and backup with our neighbor of the bfer and all these ers that have the backup, bfr neighbor of the specific bfr as primary with our neighbor.

E

With this information, we can specify a format for the bist to support fast reroute. We call this form the extended bift that compromises the information from the regular biff. That means beef, rid fbm and bfr neighbor, as well as the backup fbm backup bfr, enable backup, forwarding action and the backup entry active flag, short ba flag.

E

A fast reroute gets activated if a failure is detected, this may be done using a bfd or similar techniques, thereby the ea flag is activated for the effective forwarding entries if the primary bfr neighbor is reachable again, the b a flag is deactivated.

E

This might happen if a failure is no longer present or if the primary bfr neighbor has changed. For example, due to reconvergence, the forwarding for a bfr is adapted as follows.

E

If the bea flag is not activated from entry, normal b forwarding takes place if the ba flag is set for an entry, the corresponding backup forwarding entry is applied.

E

This means that instead of the regular fbm and bfr neighbor, the backup fbn is applied and the packet is sent to the backup bfr enabler via the specified dagger forwarding action.

E

It is important that all active backup forwarding entries are applied before the normal beer forwarding takes place.

E

And the following, I will show why it is important to first process the active backup forwarding inputs.

E

We consider the given network with seven beer capable nodes where every node is a b of r and a b e r at the same time appear packet for b of e r, b2 and b6 arrives at b1 in failure. 3 case b1, first processes the bit for b2 and forwards the packet copy to b2 afterwards, b1 processes the bit for b6 and sends a packet copy to b6.

E

There's only a single copy of the package pair involved link.

E

Next, we look at a failure case without prioritization of backup forwarding entries.

E

Let's assume that the link between b1 and b6 fails and that the backup forwarding entries for b6 are activated using dba flag first b1, again processes the bid for b2 and sends a packet copy over the link b1 b2 afterwards, the backup forwarding entry for b6 is used in this case. P2 is a valid brfa for b6.

E

Therefore, b1 sends again a packet copy to this 2, which is forwarded to b7 and in the last step, to b6.

E

In this case, the same packet traverses the link, b1 b2 twice once for bferb2 and the second time for the bfer b6.

E

At last, we look at the same failure case, but with characterization of backer following entries, b1 first processes, the backup forwarding entry for b6. Therefore b1 sets a copy of the package to b2 and applies the corresponding backup fbm.

E

The backup fbm for b6 also includes b2, and therefore no additional packet copy is sent to b2. We therefore don't get redundant packets when we first process the backup forwarding entries.

E

That means backup, forwarding entries should be processed before primary forwarding entries are possessed to avoid redundant packet, copies.

E

The extended biff can be cumbersome for two reasons. First, prioritization of backup forwarding entries must be done explicitly. Then the environment be a forwarding process is affected.

E

Therefore, we propose two variants for gift organization that prioritize backup, forwarding entries implicitly and are closer to the existing beer forwarding behavior. There may be platform-specific arguments for any biff organization variants.

E

One based organization variant comprises a primary gift, which is the same as the regular gift and a single backup list that contains the backup information shown below the forwarding, with the primary lift and a single backup lift is adjusted as follows.

E

First, all entries with ba activated are processed in the backup list. Afterwards, the primary bist is processed.

E

The advantage of this approach is little memory. Consumption and its behavior is well defined for multiple failures.

E

Another fifth organization variants are a primary gift and multiple failure, specific backup. The failure specific backup disk contains the forwarding entries for both unaffected bfers and four affected bfvrs. Its advantage is the bforwarding process is the same as on the regular lift view for three round can support different operation modes. An operation mode consists of a protection level and a be a fast reward strategy.

E

Protection levels are link protection and node protection with link protection. It is not allowed that the backup path traverses the failed link with no protection. It is not allowed that the backer path, traverses, the player, node link protection, protects against link failures, while node protection protects against link and no phase. However, no protection is more difficult to achieve on leg protection and the presented draft. We propose two deck of strategies for bsp route, powerbase be a fast reroute and out of a b based bfs, we wrote both for link and no protection.

E

Hence there are multiple operation modes for bfos reward with their own advantages and drawbacks tunnel based efforts. V-Route leverages the faster capabilities of the routing underlay. The assumption is that tunnels on the routing underlay are quickly repaired after failure, so that tunnel traffic is not affected.

E

In the case of link protection, the affected beer packet is tunneled to the beef, our neighbor, for example, via an ip time.

E

In the case of node protection, the packet is tunneled to the next next top through the underlay. If the packet is distinct for the felt next top as well. Another copy is tunneled to the next top.

E

Another option for bfr c route is l of a base bfr b route. Here the well-known principles of iplfas are applied to beer, such as normal lfas, remote lfas and topology independent mfas.

E

However, we cannot simply take the lfa information from the routing underlay as a blf. A must be a beef r.

E

Therefore, b out of a's are similar to ip mfas, but they are not always the same like for ip lfas. There are normal blfas, remote, blfas and topology independent interface, normal blfas use the backup, forwarding action, plane, remote blfas use the backup forward for the action tunnel and ti brfas use the backup forwarding action explicit in the following. I want to show an example of tunnel based bfs reroute.

E

On the left side, we see the previous network example of the default distribution tree at b1 for the bf ers, b7, b5 and b4.

E

On the right side, we see how tunnel based bfr3 rod forwards the beer packets when beef, our b6, fails tunnel-based bfc route tunnels, the packets to the next next top, when a primary next top fails.

E

Therefore, b1 tunnels, the packets for beef er7 directly to beat r7 as bfr07, is the next next top. The same applies for beef er b5, the packet for bees, erb4, is also tunneled to bbr5.

E

Sdr5 is the next next stop for before at beef rb5, the tunnel packet gets de-capsulated and the packet copy is forwarded to v4 the background path to b4 by b5 is longer than needed.

E

In this example, we have one redundant package on the link b1 b2.

E

If we apply lfa based, bfs new route, we get a different distribution tree for the failure of b r b6 b7 can be reached without a tunnel as b2 is a valid b of a b4 is reached over a terminal via b3.

E

B3 is a remote blfa for b4. In this example, b5 can't be reached with the normal blfa or remote blf. A the only possibility to reach b5 is to set the packet by an explicit path to b4 before dan can forward the packet by its default forwarding behavior to be fine.

E

This example also illustrates why iplfas and beer lfas are not the same. If b3 must not be a capable, it cannot act as remote blfa for before then b4 can only be reached by an explicit path.

E

One of the main advantages of terminal based bfr reroute, is that it simply reuses the fast fuel mechanisms of the routing overlay. This leads to a simple computation of backup forwarding entries that can be directly derived from the primary boost for plr and as if our neighbors further, the forwarding action explicit, is not needed.

E

The main disadvantage of tunnel based effort view route is that it requires a routing mla that has fast fuel capabilities. If the routing underlay only supports link protection, there is no way to support node protection.

E

Further tunnel-based bf3 road introduces header overheads, as both link and node protection need a tunnel header. Another drawback is that tunnel-based bfrs v-route with no protection might lead to redundant packets. Even when backup, backup, forwarding entries are prioritized.

E

One of the main advantages of lfa based bfas b-road is that it does not rely on the first real capabilities of the underlay. Moreover, it can provide better protection quality on the beer layer than on the ip layer when the ip layer does not support fast view route or fast reroute, with only link protection.

E

Another advantage is that a base, bfr route avoids header overheads for normal blfds.

E

A major disadvantage of lfa based bfas reroute compared to tunnel-based bfr 3., is that the computation is more complex.

E

Further computation of blfas requires routing information from the underlay to ensure that the packet does not traverse broken links or notes, in contrast to normal blfas, both remote and ti, b or lfas require additional header event.

E

If only some ip nodes are bfrs, blfas will require more remote nti lfas than iplfas, and the support for explicit tunnels may not be trivial for the next steps. We welcome comments and request the adoption of the draft. The working group document.

I

B

That worked any.

B

Questions, I don't see any hands going.

B

Well, thanks for that, michael that was helpful.

F

Okay, so the adoption thing will go to the list right.

B

Yeah we can do, uh we can do a hand now and then that gets recorded.

F

B

For less so, let's see, let's join the queue, can you.

F

B

I think I'm going to find it here. Where is it show of hands tool.

B

B

The bear with me, I have to give it a name.

B

All right who thinks this is ready for adoption. This is just a rough uh here. We.

B

B

They're still coming in we're up to eight and no descent, all right shows a good trend, we'll take it the list. Thank you much ending the hall call, and that goes to our log. Excellent. Next up, pce based beer.

B

Excellent nuns here: do you have the deck you can present.

B

There, it is requesting screen already bam.

B

And your screen is.

B

K

A

K

Okay, good afternoon, iraq experts, I am juan ali from china telecom, I'm going to introduce our products. Its name is pce based beer procedure and protocol extensions.

K

This presentation contains two parts. First, I will introduce. One may propose pce based beer and this solution. In the second part, I will introduce extension for piece piece app.

K

Compared with traditional multicast technology, beer doesn't need to establish a multicast forwarding tree for each multicasted traffic and save the multicast flow states, which will reduce the results of occupation and facilities. Large scale development of multicast service in sdn scenario, users, don't need to join the multicast tree, hope I hope, improving the management efficiency.

K

We specified preserve extensions to optimize the implementation of multi-consort registration or relocation, receiver, receiver, automatic discovery and forwarding control of multicast data by using psap messages to transmit multicast management, signaling in sdn scenario, combined combining with the forwarding characteristic of fear.

K

By using this mechanism, the unified management of vr multicast can be implemented and the impacts of bgp updates on controller can be reduced. An example of pcepr topology for build map. Visor controller, as pce is shown in this page ingress and multicast source information to the controller.

K

Where pc report message for multicast source registration, then the controller fits the registration result to ingress.

K

If the controller accepts the registration, it will save the multicast source information to database and wait for the egress information when e-classes receive itmp or mld messages, they will convert igmp or mld messages into pc report messages and send them took to the controller controller, stitch bit strings of ingress and egress together and send a new bit string to ingress where pc updates message informing the ingress how to forward or stop forwarding ingress encapsulates vr header based on each string and forwards. Multicast data based on fifth bift tables and the vpn information.

K

The number of receivers is regularly synchronized between egress and the controller or between controller and ingress.

K

We newly defined a capability flag and four objects to extend the open report and update message for psf.

K

The multicast source registration object, called msr object is used for the registration and the registration of multicast source, as well as corresponding response in report. Pc report message and pc update message respectively, flag arbit indicates whether the action of the message is a request.

K

Registration requests flag a bit indicates whether the request is successful. Auxiliary data is used to carry authentication.

K

Information moti has the receiver information object, called mri objects is used for joining or leaving a specific sg in report message. Flag asked flag. I speed indicates whether to join the requested. Sd forwarding label is used for distinguished receivers as a forwarding layer.

K

Forwarding indication objects called fi object is used for informing ingress to forward packets of a speed specific sg2 receivers in pc report message: f, flag f. This indicates whether two stats forwarding multicast data.

K

Multicast receiver states stage objects cause miso. Mrs rise object is used for signalizing receiver information in pc report message and pc update message in report message. The number of receivers refers to those connected to egress in a specific sg in update message. The number of receivers refers to all receivers in a specific sg.

K

In open message, beer multicast capability flag instead for pce capability tray in the open objects need to be set to spot via multicast report. Message is extended to optionally, include, msr, mri object and mrs object. After the path object, update message is extended to optionally, include, msr objects, fri fy object and imrs object after the past object.

K

That's the main content of this draft. Any comment on our work are welcomed. Thank you.

F

Okay, I seem to be only ma uh one of the mic uh suanam thanks a lot interesting um presentation, truly valid, um so two observations from my side. uh That's just one way to use a controller architecture with beer right which I would consider a low touch, because you just touch basically the egress, the ingress of the network.

F

uh It's absolutely conceivable, like with brte that somebody goes and programs all the gifts into all the notes, and has you know a very high touch control architecture or they will do something similar to you, but with you know the beer fr specifically as just suggested here, so I would be reluctant to call this thing. um No beer multicast capability bit on on a pc call it something else. You know give it a more distinct name.

F

So this is, you know this light touch, control, architecture that you're introducing here or otherwise talk about no generalization what it means beer in pce when you use the different deployment models.

F

The other observation is that your packet formats are very tight.

F

I would make them a little bit more flexible using tlds, because you may be adding more things into the signaling later in the next versions, uh whereas right now, it's all pretty hard coded and very tight. You know, like it's auxiliary data being authentication, so you can't add. I don't know backup whatever you know you, you may have backup domain with the backup, sub-domain or something you know like we do it for lsps, primary secondary and so on.

F

So again, uh one observation, um don't call it beer, you know capability, because there will be other deployment models, so call it. I don't know beer light touch, pc capability or something or make it more. Generic and second thing whether you don't want to break up the packet formats into a little bit more flexible, tld format.

H

So when you add new things, you'll have a.

F

You know easier.

H

F

To do that, sending.

F

H

This is jeffrey.

F

Everybody's yank sorry.

L

um Okay, so we record beer flow overlay, which is the beer flow overlay.

F

Something I'm okay. I have. I have no opinion, I just you know, I'm just pointing out, which is one.

B

B

Looks like we wrapped up one more questions.

L

Yes, can you hear me.

B

Excellent, very good! Thank you for that. Now we're uh all right! I'm oh you're! Here! If can you have the decks.

A

You can present.

B

Yeah, excellent, okay, I'll grant. You are granted, take it away.

L

L

Okay see my screen.

B

B

Still don't see it so I granted uh your status shows that you are sharing, but all we see is the uh the box text saying the screen sharing is being started. Is there something on your end, you've gotta.

B

Confirm anyone from meat echo here.

F

Yeah, why why I don't see the top either.

B

F

B

Go okay, your shares coming up excellent! Okay! Good! Can you see in the slides? Well, not yet we see the fractal display of your screen going into infinity, uh so select your slide. Deck and it'll take over.

B

No, no you're right now the web displays what you have up. You need to display your screen. Your of your presentation is that a different application. I just opened the powerpoint.

B

Yes, so can you see the powerpoint slides, uh open them up and we should see them pop up.

L

Yeah open it already open the powerpoint slides.

B

Well then, select powerpoint, because right now the focus is on your web browser.

L

So just full screen: can you see the slides.

B

No we're still looking at your web. Your web browser at the meet echo screen.

B

That's interesting! Okay, do you have two screens.

L

No just one one screen.

B

Okay and you're, what are you looking at? Do you see the reason? Oh, your sharing just ended so go ask again all right, yeah.

D

That's right what happens granted.

B

B

B

I should run out boom. We got him very good. Oh.

L

Good finally, we got it. Thank you very much very patient.

L

So today, hello, everyone. Today, I'm going to talk about the ospf extensions for brte.

L

B

L

For every b fr id of equals node, those id has already been distributed through ospf. So in dt's term, those ids for egress node is called a local d-cap adjacency in prt for every link.

L

There's a bit positions is configured on each end of the link, so this bit position is called forward connected adjacency in bat system.

L

So, for example, in this topology we have equation of d has appear id1 we have equals. Another f have an id2, and so on so for each equation: node d, f e h and a we have ids those ids already distribute in the network through igp for each link in bite. We have repeat positions on each side, each end of the link, for example, for link between h and the d.

L

We need to configure two bit positions. Each bit position is configured on each end of the link, for example, on on endohome, on h, node h, and we configure each position 28. Prime, on node descent. We configure b position 27, prime, so for each of these speed positions, so we propose to distribute these these bit positions for each link through ospf. So most specifically through ospf version 2 right now.

L

So after distribute these uh positions, so we can have uh take advantage of this information because all the information is about the id for eagles node and the b positions for each of the link already distributed in the network. So in the every english node of the network that the english node can compute a beer tier plus corsair network.

L

In addition to that, every bfr node in network they can compute a local backup path for providing protections for its neighboring labor nodes, for example in this topology. In order to provide protections against the failure of load c node b can compute backup paths for node c, so node b will compute the backup pass to c, like top, for example, f, so node b will compute the local backup, plus, from b, to f so b to f the bypass is from b to e and then to f.

L

So it's in the red color, so node b can also compute bypass from b to d, which is microsoft of c. So the backup path, from b to c is from b, to g, to h and to d so, which is in green color b. Can also compute background, plus from b to I, I is also negative of c.

L

So with all these background paths, node b can provide protections for any bft path goes through b to c, when c fails.

L

So for ospf version 2, we already have extended link opec analysis, so these all packers says can contain multiple trvs, so this prv can include extended linked lvs in this extended linkage of this we define a new sub trv, which is called vit subtitle v. So this bats subatov will contain the information about the positions of the link.

L

So this blt subtract v in fact, is the extension to the ospf v2, so this sub plv mainly contains the view position on one end of the link attached to the total node. In addition to these projections, it also contains sub-domain id and the monitor objective and the b algorithm and ib algorithm and so on.

L

So that's about the old spear version, 2 extensions for bates. So any questions and comments regarding the business.

F

Draft see the name affiliation. Please.

H

See lindema cisco systems hey, uh we know I was just gonna say that in ospf for both this this extension and one for ospf v3, we don't use, we don't have. I know you don't define any, but we don't use the uh moniker sub sub tles because in ospf, because we you can nest steal these to anything to any level.

H

So we wouldn't want to keep adding sub on the pre-pen sub for each level of nesting. So everything.

A

You're, just like.

H

Yeah, so everything that's not a top level. Tlv is a is a sub tlv, you don't need sub sub or sub sub sub or anything like isis does. Okay,.

L

Thank you. Thank you very much for your comments.

L

L

So next one I'm going to talk about the osp version, 3 extensions for.

L

Bte, so this is similar uh to old spear version two. So in ospf version three or we already have extension, the router says this router says may contain trvs so that the trv may be a router ninja trv and the router-lingered dlv can contain plvs phd tlvs.

L

So pltrv will contain the bit position and partital node, which advertise the the model say.

L

So the bft trv has the same structure and the contents, as we already presented for osp version 2.. So it will contain mainly contain speed position on one side on one right side of the link and sub to my id, multiple quality and so on.

L

So this is the first uh almost same as ospf version, two just use different lsas and the tl trvs. So any comments regarding to this. uh This draft.

L

So I'm going to next one, the iss extensions will be 80, so in iss we already have a trvs of type 22 and 222, so for trv of type 22.

L

It may contain subtlety of these. So in this sub trv we can have a bat sub material this. So this subtle v will contain the information about the speed positions configured on one side of the link, in addition to that, the trv of type 2 to 2, which is for modded topology so in the environment of model topology, so that multiple trv can contain the structure of trv over type 22.

L

So in that, in that case, the structure of trv of type 22 can contain, be it bats after vs.

L

So if, when eventually, we extension is a bat subtle v's, so the the blt subtlety here has same format and content as we talked about, except that in iss the type is one byte and the length is one byte in ospf the type is two bytes and the lens is is too bad the addition, after the night, everything is the same.

L

So any questions regarding comments for this draft.

F

Yeah miner tony p juniper, if you can flip to the previous slide, please one.

L

F

The next one 13 yeah, so only observation, is uh for the big position and the end bit position. I would put one reserve to align those on 16 bit: it's extremely painful to power staff and put together numbers if they're, not on the on the word boundaries.

L

F

Good yeah yeah, that's very.

L

L

Yeah we'll change that one in the next.

L

C

L

L

L

Yeah, I'm done I'm down for my presentation. Thank you.

B

God any questions on this. Oh, I see your last slide. There oh got it. Okay, it didn't go down to a go down, one more slide boom there. We go all right. Any questions on this or the previous.

B

One pretty solid, um so the intent I imagine for the all three of these would be to for adoption and move this up forward. Is why we're here in the first place brand new? I honestly yeah, I I did slip this time. I have not read all three of these, so I'll refrain from comment, but let's just do uh I guess we should let's do a hands for each one of them just so we have a cue and then we'll take him the list we see intent from here. All right. uh I will begin.

B

I remember how to do this gallery clock no need materials show of hands tool there. We go all right I'll, just give the adoption name bear with.

B

B

Session started, so, if you think should be adopted, raise your hand, uh you can actually do a do not raise hand if you choose.

B

B

All right still coming.

B

B

Seven says ready: one say it's not still pretty solid, we'll take that to the list and get some action all right, I'll end. That session here comes the.

B

B

uh Rurik, did you have a question or you just trying to raise your hand for the.

B

Call all right beer, tea, osp, v3, adoption.

B

B

Settling on six.

B

All right looks good, we'll take the up to seven now, no dissent.

B

Once twice ending session, we'll take that to the list and one more, the teisis draft.

D

B

Right looks like people figured out the tool quickly, this time, nice.

B

All right even more support we're up to nine, no descent. That was quick, very good, all right, I'll end that session. This will also go to the list.

B

I want to thank all the presenters for being prepared with backup and slides ready to roll. That was great. uh I know we get lulled into complacency when we have tools that work well- and I have to say, medieco has worked really well in the past a little snafu, probably just because of our move, but that uh integration was great and nice to have the slides prepped when things fall apart.

B

uh Tony had a question: no v3 extensions. Did you want to take that to the mic tony or is your mic.

F

Yeah, where are the I admired version? 3 extensions. Of course only the igp people will get the joke.

B

Fantastic, okay, uh anyone not sign the blue sheet. I just said: ask that you know we don't blue sheets. This is great we're actually early, uh which is wonderful.

B

Do you have any press and info stuff want to run off to other groups, we're ahead ready to roll anyone hands a d anything to yell at us about give us a direction for not just in the direction, nothing that was smooth. Thank you everybody again, thanks for your cooperation and patience through the text nafus and our ability to adapt and respond and present regardless, when the question came up, nope all right, thanks, amaro, thank you, everybody uh and thank medeco for uh making this work for us have a great week. Everybody.

F

B

Hey if anyone's still on and you're going to chair something going down the road, I found the upper right corner uh the wrench button.

B

You click on that it gives you up and do manage slides, and that seems to have the link to the data tracker, whereas the presentation folder didn't so it's still there, just the link's broken. If you can find it up in the right-hand corner, you might have some better luck than I had close that all right.

B