Internet Engineering Task Force 110, 9 Mar 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF110-LSVR-20210309-1430

Description

LSVR meeting session at IETF110
2021/03/09 1430

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

A

B

A

Okay with uh at the start of our slot, so we only have like one hour, so you know maybe let's get started there, so you have landed into the lsvr working group and uh we have a few interesting topics here now before we start. Let me see if my slides actually work. Okay, so we don't need the scribe thing, because we have the scribe automatically building into the tool nowadays, which is very handy.

A

uh If there are like any minutes, then you know, please feel free to use the menu tab. You know on top of the uh meet echo screen, you don't have to do this, you know just by yourself. We can actually all do this together. So that's very hands handful. You know very handy and very convenient, so that would be appreciated uh next, is you have seen this note well already a few times because we're already on the second day, if any questions you know, please be aware of this, then the agenda bashing.

A

So what we have on the agenda at this point in time is uh three topics. Three main topics here: uh first, we're gonna get like an l3dl uh status update. Then we're gonna have uh paul speaking a bit about ldpv2, which is you know what is happening in the ieee.

A

From that perspective, then we're going to be discussing the announcements and the progress around the bgp spf itself and see where we are and then we are going to be closing.

A

So where are we within the in our working group here? So we have sent two documents towards the id the id reviewed it and actually, you know, send it back, but you know together when sending it back, he actually sent. You know it back with like a thousand one pages of feedback which uh the authors have been working upon very intensively. You know over the new year's period until now and ac is going to give like uh an update on where we are at this point in time with these particular drafts.

A

Now, in the meantime also last month we have done a working working group last call on the l3dl documents, uh while no major concerns were erased. You know there was also not really a lot of feedback on that. So you know we need to figure out how to deal with that going forward now. That being said, there is another element playing also, and that has to do with the fact that l3dl is a little bit out of scope from our shorter.

A

So what we are thinking about doing is to reshorted the working group uh by explicitly adding the l3dl components into the charter itself, which would give us you know a better foundation to keep progressing on this particular technology going forward, and that being said, you know for in an effort for trying to enhance the feedback required. You know, feedback requested and reviews requested for these documents.

A

I'll also be you know, launching a call on the working group email alias for some volunteers to actually give feedback on this on these documents. uh Just you know more discussions on that going forward.

A

You have anything to add on this victor.

C

It pretty much covers it all right now that covers it. From my perspective as well.

A

Okay, so yeah, I already talked about the dietary, please status element here, which paul is going to give us an update about so going back to the agenda. Any anybody wants to add or change something on here at this point in time.

A

If not, I think, then we're going to be starting with the first session and the first slot from randy.

D

A

So let me pull up the slice for randy uh voila, so randy. If you can push the microphone button, then the floor or the worldwide internet is all yours at this point. You think.

B

Well, I could only use this very small portion of the internet.

B

um Okay, this sue um raised an issue by a private email which was interesting, um but first just a little bit more on status is the documents the three l3 tl documents passed within the class call with, as gutter said, light feedback, but um you should be aware that also that rob is contemplating upgrading updating the lsoe open source implementation to l3dl, so that kind of wraps the status so sue raised an issue about the hello pdu, possibly causing a layer 2 storm next slide. Please.

B

If you remember the hello is a multicast layer, 2 pdu being sent from a device who wakes up and is seeking friendship. There are two forms the pdu can take. One is that first mac, which is stopped dead at the nearest bridge by layer, two rules.

B

Okay, if just in case there's an intermediate switch, we specified a to be assigned mac that will pierce an intermediate switch because by layer, two rules when a switch receives a frame with a multicast desk that doesn't recognize it forwards.

B

Okay, so the second one is to be used when you know you're connected to a switch next slide. Please.

B

So the document says that that hello should be repeated at a configured interval by the default of 60 seconds. So when the device wakes up, it should find its friends within a mean of 30 seconds and a max of 60 seconds, but it further warns that, if you're in the multi-link scenario, in other words you're allowing for intermediate switches, be aware of a trade-off between the timer tuning and network noise and maybe tune the timer up or down accordingly, but sue raised a further issue next slide. Please.

B

Next slide, please so I've stolen her artwork sue. Do you want to um walk through the storm or shall I do it? I think everybody knows what a way or two storm is like, so we can breeze through the storm as it were, or we could if you've got the patience you can take us through it.

E

B

E

By not um that means.

B

E

They need to enable me, did you get me, can you hear me gotcha.

F

E

Okay, I would go through the brief, because if people understand multicast storms, this may be a simple issue. uh If the brief doesn't make it we'll go through the more lengthy approach.

E

So uh folks, the diagram, I'll explain and then I'm gonna, let randy go through the discussion because he tends to be a bit briefer than I. The concept is you don't have the topology described in the document? Okay and randy will go through it, but you have this more interconnected, switch topology. How you got there, not my problem.

E

uh Perhaps it's recon errors, and so this is the aero topology note I realize it is not a standard class topology. It would be created by air or by something else, so randy. Why don't? um Why? Don't you go ahead or I can explain the next step.

B

It's fine so essentially the routers, the things labeled routers are l3dl speakers, the things not labeled routers, the little square, cubes oops, that's bad! The little cubes are switches, whereas if you use the multicast to be assigned multicast packets will go not only through them, but it will as it receives one next slide, please it will re-announce it.

B

Okay, you see the multicast hello coming up from router a and switch one re-announcing app on all its other interfaces. Next slide, please those other destinations generously do similarly and we can see more pretty colored little boxes. Multiplying the network next slide, please those in turn echo back now. What was fun here is that, because the echoes caused regeneration, they go back.

B

They're allowed to come back through the mesh and are even worse next slide. Please.

B

So I think you see where this is going. If anybody wants more detail on layer, two storms feel free to hit your mic button.

B

G

Bill hi, you have a layer, two network without spanning tree, but with loops like how do you get to this point? Where the switches are flooding and creating a storm.

E

That's a good point: this is an edge case bill. The spanning tree is most likely not running. You would have some interconnections that are are um normal. So, as I started out in the beginning, this broadcast storm only works with the compine with a set of edge cases. Okay, you don't have something: that's living running a spanning tree you're using uh the multicast transmission, which goes through switches and then redistributes widely um paul. I don't know if this is even possible.

B

Just just bill, let me see if I can cut to the chase here- excuse the spoiler the final scene of the movie. Is this? Isn't our envision topology in this working group? This isn't a club and there's tons of intermediate switches which we don't envision. Envisions ls are enabled device ls vo to enable devices all on link to link just in case, but we can move forward. Let me move forward next slide. Please.

A

I think we also have paul actually in the line here.

H

Yeah I just was gonna echo kind of what bill said. We have it obviously kind of an invalid layer, two topology here there's besides multi-caps, there would be other flooded packets that were not learned yet or various things. So I also wanted to point out spanning trees, not your only topology management protocol at layer, two there's other approaches, including software defined networking things or as well as shortest path, bridging and so to make this work. There must be some kind of loop free, topology management going on that would prevent this. I mean.

B

My pope, my point, is: I don't want to make it work. I don't think we're interested in it, but we'll I'll get there in a minute next slide. Please, okay, one approach. Aside from as paul and fenron point out on trying to use standard layer, 2 damping tools is, do we add a nonce?

B

No nice. Try, because the p naughts would be recognized by those non-l3dl speakers, so the storm would propagate next slide. Please.

B

But isn't this isn't our model? Okay, we don't have a model with all these switches with this dumb switch mesh next slide. Please our model is a club, a standard, clothed fabric and they're all 3dl speakers next slide. Please, at worst, we might have a switch that wants some fan out, one stage, which is why we stuck that one form of switch piercing, multicast mac, okay, this isn't going to storm next slide. Please so do we actually have a problem and that's the end.

E

Comments is because I think it's an edge case. I didn't perceive anything that really needed to be fixed after our discussion with randy and I couldn't think of uh of a shortest path, bridging or normal, spanning tree topology, where this would actually apply. I I just thought outside the box, so I'll leave this to bill and the rest. I didn't think there was a problem because I don't think the scenario I described is something you would normally see now that I've shared my evil nightmare I'll. Let the rest of you.

G

uh Just um there are other packets, like broadcasts that also need to be um not uh create a storm and multicast is just another instance of this. So you need to have some mechanism spanning tree or s or as paul said, there are many other mechanisms in your layer two to prevent storms. It's not just multicast that has this problem so to have a layer. Two like this is just to have an invalid layer too. It's not just this particular multicast that will have a problem.

G

It's broadcast arps, it's unicast, unlearned uh flooding, so I think the pro, even though, even though we don't need this, you know we don't want to address this topology because it's not a clo. We also don't want to address this topology, because it's just not a valid layer too, to run over.

B

um I agree first of all, um there's a hidden issue here or desire here, which is over an idr they're discussing bgp discovery. Finding your friends and their immediate target is the data center.

B

I don't know if they are limiting their definition of data center to be a clo.

B

As far as I can tell they're in the expansion and laundry list phase.

B

But I think this probably triggered the oh, my god. What happens when there's all these other devices here?

B

One thing we could do is by the way is ignore or actually prohibit the case when there's an intermediate switch and remove that second form of mac, I'm not advocating it. I'm saying you know that certainly shuts off this possibility of.

A

Discussion so one of the.

E

Things you know yeah, I got here.

A

Yeah, I was just wondering about the fact you know so if you look into the layer, 2 topology what we have here, you know it's a little bit illegal because it represents a layer, 2 environment. Without you know a spanning tree, or you know some sort of a protocol to do. You know to manage the multicast and broadcast floating within the environment, which is a little bit. I think illegal. It will give problems always so I think we should. You know to me.

A

We should the l3dl should support like multi levels of you know, of of switches, but we should have a floating mechanisms. You know that should be. uh You know a requirement. I think. If we, if that actually happens, it should not be not what I'm thinking.

B

um I think everybody's discussed the fact that that topology is not something you want to write home to mother about, but that last statement you made is that l3dl should support multiplayer switching topology properly configured, of course, is that really a target for lsvr, and I'm asking you as chair.

A

From lsvr, I don't think that is the case, but then again I think l3dl, you know is a technology which could be used potentially beyond. You know the lsvr use cases, so I don't. You know, I think if we constrain it too far in the applicability at this point in time, then, in a later phase we will have to do you know more r d research to expand. You know the use case from it.

G

H

Yeah I was going to respond to your comment about maybe not using the um address that passes through switches and using one that terminates at switches like lldp might and there's probably a couple of ways that you could do that.

H

First of all, in 802.1 we do have regis attribute registration protocols that allow you to propagate information like who my neighbor might be, or something about somebody across the network like that, you showed uh without flooding and without you know, without causing the storm so there's there are separate registration protocols that could be leveraged, but perhaps even easier would be to to find your own like higher layer entity that propagates information using um you know hop by hop kind of methodology. So in other words, we do this in lldp as well.

H

You you, you may receive uh some information on one link and then you generate an entirely another packet, rather than just using the forwarding plane. You use the software plane, you generate another one that goes out the other links um that sort of propagates that information, so you could conceivably build some higher layer uh entity.

H

When I say higher layer, I mean above layer two, so um you know some software forwarder so to speak, that that just regenerated the l3dl information and sent it in a whole new packet rather than just flooding it so anyway, just a couple of thoughts. There's there's possible ways. I think you could do what you were proposing.

B

I

Hi randy uh jeff has juniper.

I

The the point from the auto conf, I suspect, was the genesis for this conversation, but I think it probably still impacts health lsvr as well.

I

The observation that we'd left in the documents that we did for auto conf is yet to figure out what is the scope of the thing you want to talk to, in this case we're talking about l2 and I think, you've nailed the point perfectly fine that if you use something that goes beyond the scope of the thing I'm talking to at the end of this wire to a broader domain.

I

If you have a mis wiring in your network, it's potentially problematic. I'm not saying that you should solve that.

B

And some some operators have told us one of the things they like about this is it might help them detect miswires.

B

I

No, I I agree with you um it's one of the things I do like about l3dl is that it's good plumbing to extend for a lot of things, including this use case.

I

I think that we both realize that, if that is part of the core use case, a little bit of additional machinery needs to be added to the protocol.

B

Gladly discussed thank.

B

You my forward proposal at the moment is this is not our problem in l3 and ls. We are if people over in idr want to.

B

Use l3dl, certainly we can discuss it with them.

B

Somebody feel free to whack me on that.

B

Okay, then I'm done.

A

Okay, cool. Thank you. Thank you randy. So, let's jump to the next one. I think this is going to be paul now.

A

So, instead of five minutes, you actually have 10 minutes well,.

H

Okay, I I'm assuming you can hear me: okay, yep um yeah, so it's been a while since we've, given you an update on what we call project 802.1 abdh, um which we we call in 802.1x lldp, but we've talked in the past about it being called sort of lldp version, uh and the main the main objective here was to allow us to send more information in lldp than can typically fit in a single frame, uh but do that in a way that is backward compatible, so it uh I I have some uh well.

H

First of all, we have an editor uh who's been developing. The draft uh steve haddock, you may or may not know him he's been around for quite a while excellent editor uh and the pro the draft has made quite a bit of progress and sort of getting to the sign of final stages. If you will so next slide, um because first of all, this is a an individual contribution. This is not an official kind of quote liaison or anything from ieee 802..

H

This is just me, however, if if lsvr was interested, we could do uh something a little more formal in terms of document sharing and those kind of things so making it possible. For uh you know, your lsvr group to you know, comment vote whatever on the documents, we're typically very liberal, about accepting comments from from anybody anyway uh in the earliest phases. Once you get to the final final phase, uh then of course it's a things are processed a little bit more tight, but in general we're open for comment so yeah next one.

H

um So briefly, this is the uh I didn't want to get into. I don't have you know in five or ten minutes still not enough to do a lot of technical discussion here, so there have been uh presentations in the past.

H

I point out that the the motivation for originally doing this work came from um looking at the requirements that ls l3dl was satisfying uh and trying to see. If it was time to update lldp it's a widely used protocol.

H

There were a lot of people that have augmented it or added additional information, and it really pushed the boundaries when it only allowed you to send a single frame.

H

So the l3dl motivation helped kick us off into this new project in general. So there's some background presentations here and again. Last time we did an update was itf 106., but nothing really has technically changed. Since then, um I've just got some references to pointers for the project page and then the project, scope and those kinds of things you're welcome to read uh and then more recently, the the sort of technical contributions um as steve haddock came in and became editor. He had a couple of questions and he noted a few things.

H

We had resolved those those are discussed in here uh and uh there's a paper written by myself and paul bottom, who kind of goes into really more of the details. That's the fundamentals for the for the uh the draft so feel free to take a look at those. I think those are all publicly available documents uh next slide.

H

So, since the last uh the status and since the last ietf um we've completed what we call the working group ballot, first working your ballot and that was very recently completed, it's kind of roughly equivalent to an ietf last call and we're resolving those comments. Now uh this week, as unfortunately, ietf and ieee overlapped at the same time so made difficult to attend both, but really the changes are we put all the content into the format of a standard we?

H

That draft is complete with all the normative texts and state machines and conformance we're using this xlvp terminology to to express the extension of lldp. It's not necessarily a version two, because what's important is that a version? One implementation, that's probably already running in the network, is capable of communicating with the version 2, but obviously only the first pdu's worth of information.

H

But in that pdu we we defined a new, a new tlv that basically describes a set of extensions um and uh and all that information allows you to send up the like 64 or more pdus worth of of data, and one technical thing that came up lldp supports the concept of uh multiple agents per interface and really there's different scope in l2 networks.

H

You might have provider bridges or provider backbone bridges which are kind of layers of layer two, if you will- and we want to be able to communicate, lldp messages between different endpoints across that layer to topology, and so there was some there's some trickiness in how that works, but we made some clarification of that in the standard. So it's always been there. It's not new support, it's just when we added xldp uh capability. It got a little bit more interesting so um next time, so the next steps is again we're resolving comments on uh thursday.

H

I guess it is this week um and then we'll have what we call recirculation ballot. If that passes, then it goes to uh what we call standards. Association ballot, which is kind of you, know the equivalent of the end of the road uh and um what would be great is to see an open source implementation. You know the current lldp open source implementation would be would be great to see that augmented to support this um and then, like I mentioned early on, if there's a desire, we can do some liaison and document sharing with lsvr.

H

If, if that's of interest, we can take that offline to to roll those wheels, so if anybody's interested in doing that so anyway, that's that's. Really the update. um If there's any questions happy to take those.

A

Thank you paul any questions at all. If not, then we're going to go to the next uh slot.

H

J

Yeah, no, this isn't just a question. It's ac linden, cisco. I want to say that I think this is a good work. uh I'm hoping I recommended that cisco support this, even though I'm not active in the ieee, so I'm hoping that happened.

H

uh Yeah we did get your support to make it all happen. Thank you.

B

B

H

Randy helen.

B

I did uh come over to ieee and try to help and join this, and nothing much was happening if things are spinning up again, I again volunteer to help.

H

Okay, let me know how we make that happen. I can uh I'll bring that back to the group and mention somehow we can as an individual work you in or or again we can do a more official cooperation.

B

I'm just an old hippie engineer, so you can wrap whatever you want around it, um but email works well.

H

A

Okay, that's it!

A

Okay! Let me get the last section to the last button.

A

A

Okay, here we go.

J

Let me adjust here good morning: everyone I'm going to be presenting one thing: uh I'm only good. We we well both documents went back to the working group. We focused on the protocol document with updates. We were doing uh during uh starting about thanksgiving care victor and I met weekly and and went through the comments.

J

Actually, as gunther said, there are a lot of comments. I think the the comments plus the inline draft, greatly exceeded the size of the original draft.

J

So there was a we spent uh quite a bit of time on this on the first document. The reason we didn't look at the apple applicability yet is because uh why don't you go to the next slide?.

J

Because the applicability uh will be impacted by the change, the the protocol in a lot of places when we first did this, we thought something with bgp. We said yeah. We could do this with bgp spf, but we took out all those things that we could do but didn't fully specify, because we wanted to have a nice tight core protocol that could that can be augmented with future uh giraffes to do more things with it uh a lot of the comments.

J

These are just things we did. We beefed up the error handling we added the security section with the parts of it that are relevant to bgp spf. We clarified the relationship to bd bgpls and uh you know. In addition, we've always had the separate address family, but we clarified that clarified, which um nrli and which uh attributes we were specifically using in the base protocol, and we also um also like I said we eliminated things in bgp that we said you know. You know uh like, for instance, uh route optimized route reflection.

J

We took that out completely. We took out uh some of the other discussions of 55 49 next tops and things like that and I rewrote the or we rewrote the spf section and used consistent terminology throughout. I think I think it's a lot easier. I mean it would be.

J

uh There were actually some mistakes in it too, and once we did that so I know the implementations must, I hope the implementations just said. Oh I we know it, we know what it what he means not or what what the draft means, not what it says and some other minor nets next slide.

J

Yeah most the changes were clarifications and things that should have been. You know where we underspecified.

J

There are weren't a lot of changes to the protocol other than the error handling. I mean that that really really crisp that up, because he's familiar with all the different, the evolution of error handling in bgp, complete with uh the um the draft. I forget the number of it that tells what you do uh when you, whether you ignore uh an attribute and continue or whether you, whether you uh take it as an implicit withdrawal or bring down the session.

J

We tried to stay away from that last one of course, and uh we put in the uh the code points used by the arcus implementation into the ant ayana section and have requested early allocation of those next slide.

J

Now this is really the key point. There were a number of things we didn't put in yet, but I think most of them are closed.

J

We inherited because we used bgp ls nrli, we kind we pretty much inherited that you're going to be limited to one nrli per update because, conceivably, you could have a bunch of prefixes that all have the same metric all the same attributes, uh but if once you start like that, if, if anything ever changes, you'd have to keep them together because of the sequence number everything.

J

So I think we're going to go ahead and say really you really really only can have one nroi per update, I'm going to go to I'm going to do initial synchronization last the next top requirement, okay or crisp that up. So it follows the 4760 rules, and I think this issue is closed completely and the single session requirement. This was from melbaro, but we he said he said. Are you limiting it to a single, uh a a a separate session for bgpls and the other address families?

J

And we can take that. We think we're just going to verify this on the list. We don't think it needs to be so we're not going to do this. Okay, let me go back to the key one that we're going to discuss. This is the initial synchronization.

J

What alvaro brought up, which is a really good point, is the igps at least ospf uh has a you know you don't advertise a neighbor until you have synchronized with that neighbor or the link that it's you know. You know that you're connected over that link to that neighbor.

J

Now uh we'll have we're going to add some discussions of this. I guess isis has a a similar thing that you don't advertise, but it's not mandatory in isis, I forget the name of the the bit in the in uh isis hellos, but anyway um we're going to discuss that further on the list. The one thing that I was thinking this is just me I haven't even talked to my co-authors about this is maybe we could push the route reflector case out or the controller case.

J

You know talk about that, what you could do or whether your mileage will vary or whatever. So that's what's coming next slide.

J

Like I said, we're gonna, we we did. One working group last call we're gonna do another once we get this done, we'll start working. You know once now that we know we've sort of scoped the base protocol down to what we've fully specified we're going to work on the applicability as well, and there are now multiple implementations. There's a there's, arcus and one underway for uh with for free range routing.

A

Comments, hello.

K

uh Hey guys good morning, um albert athana, um uh futureware technologies, I guess speaking as a individual working group participant at this time. um I just want to.

K

I guess, if we go back to the last slide, the slide before this one um insist a little bit on the separate session requirement or maybe not requirement considerations, because um not only are we carrying different information inside of bgp session, but we're making decisions based on different things, meaning running spf here versus the decision process in 4271., so the potential dynamics of how the updates get distributed around the network are different from a normal by php session to a bgp spf session.

K

So if the working group- so I would you know I'll- obviously uh really want to see a requirement for software session, but what I would settle for is if we could include a draft. um You know some considerations around. You know what things um could happen. You know what what things to look at in the network- uh I don't know congruent topologies things along those lines, just the individual contribution.

J

I'm gonna know that I see carriers in the queue I'm gonna. Let him talk.

L

To that one super, uh first of all uh cave patel's uh arkis, I was gonna, say cisco, uh following ac patella.

L

One thing I wanted to uh first acknowledge was that it was a fantastic feedback from alvaro um on the draft uh we couldn't have asked for more, um and so thank you on that, particularly on a single, a single and a separate session requirement to me, we could certainly add some text in the draft, but this is also somewhat an implementation uh detail in sense that today certain bgp implementations do allow you to run multiple processes, wherein you can listen on a different uh ports uh over and above 179..

L

So you could definitely fork this implementation of some different port where you could listen on to and then it would automatically be a completely separate session.

L

So whether you want to do that or not is a very implementation, specific details, um a lot of people do it for a lot of different saffies and that's why I think we can add something in in draft as a loose text, but we won't want to make it as a requirement.

L

J

Right the period I mean yeah, you wouldn't want to have you you know, especially if you're doing the purine model, where you're using a session per uh per link. You certainly wouldn't want to have a separate address for peering on two addresses to make them unique.

L

Yeah the separate listener port would typically make that session completely. Yes, yeah.

J

That'd be a better.

L

H

A

J

I I know what he's asking I owe him a response on this.

D

Oh, I have a question that I found the from the job to version. There are at a new chapter, 6.1.1.

D

This, I think this is this. This actually is like igp method, but uh for bp obpa.

D

Perhaps the s loop or maybe check, may be used or other otherwise of the ordinate id may be used to identify the rule. So I think this uh scenario perhaps may not be happened in the bpspf.

J

Yeah, I I remember this one from the uh from the email he sent. What he's talking about is the fact that we uh we have handling of self uh self-originated nrli and by self-originated I don't mean I don't mean enter a lie from your neighbor. I mean enter a lie where the node descriptor in the bgpls uh nrli identifies the uh receiving router and we do it and- and I had added something to do it like the igps to speed the convergence. In the case, um I don't know if we don't think we.

J

Let me talk about that with uh with the co-authors on the list we can see. If we we don't need this, uh but that was added yeah that was added to speed convergence in the. uh In the event there was stale nrli, but granted it should all go away as it permeates from the you know, from the from the uh source from this from the originator.

J

Just take might take a little bit longer without.

J

D

J

We have a rule that you always if, if, if the uh this is to cover the case where the router restarts and loses all its stake, we have a rule that if you receive nrli uh from the originator, you will uh you will in fact prefer it, even if it has a lower uh a less recent sequence number to take care of this case. So probably maybe we don't need to discuss, discuss the uh uh the self-originated case. I thought about that as well.

F

A

Any any more questions.

A

A

Okay, this is the last slide.

J

Oh yeah yeah right right, yeah, the yang model work is in progress in uh care care and associates are working with it. uh We're gonna work on it.

J

uh We're sort of. I guess the bgp uh yang model has gone through one last call, so it would augment it would augment the bgp la uh yang model in idr, which is pretty big already with a new address family.

J

Our new safi well k are: you want to talk to.

M

That are we going to do all of bgpls or just what we need for bgp spf.

L

um We were thinking of doing it just specifically for bgp spf, but it would be generic enough to extend it to ls eventually, and maybe, if we have an agreement, if the chairs have an agreement with the chairs at idr that, then it could be a common draft, but what we don't want is to have a perception that we are taking over idr's work. So if there is an agreement, we'd love to do it at a common place, I think it makes sense, also, but then again I'll defer that to chairs.

L

I think we should defer them to cheers.

A

Of which you are one of them from idr nowadays, so it's gonna be.

A

A

A

That's it uh victory of any last words to say at the end of the session.

C

Specifically uh we'll talk, um I guess we'll take that as a output sort of how we're going to deal with that along with idr, um and then we will be processing some of these updates and getting and we'll. Let the working group know by mailing list when ready for the next working group last call now ac.

C

One question I had for you is: um I guess we have to discuss whether we want to last call the b2b spec before the update to the applicability draft or if we want to get that rev and then kind of send them both in as a pair.

C

um If we, if you don't, think it's going to take too long to get the applicability updated, then perhaps doing it at the same time, maybe simplify things. Did you have a religion on that.

J

I don't no, I don't uh I I wouldn't mind doing separate cycles, but.

C

Okay, I'll discuss with gunter and headline.

A

C

Oh wait: alvaro has something to say here.

K

uh Hey, I love that about you, um so I would prefer to we're going to publish them both publish them both together. That doesn't mean you have to last call them at the same time, um you'll progress through my q and I'll just push them both together at the end.

C

Okay, all right so I'll, just because of gunpowder. We were talking there about how to deal with the working group paul, but it's understood and noted that, uh when we're ready for publishing that we put them that they should go together for simplicity reasons, no.

K

Right, so if you send them to me, you can send them to me independently. It doesn't matter I'll, just at the end.

C

Got it, but you want to go to the isg once I understood.

C

A

Okay, I think then uh I guess we'll finish that you know we give you back like eight minutes of time before stepping into the next session. Thank you.

C

C