Internet Engineering Task Force 104, 27 Mar 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF104-LSR-20190327-1120

Description

LSR meeting session at IETF104
2019/03/27 1120

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

A

I know, but it's not, but it just does its broke. It's a button.

A

A

B

Everybody we're gonna get started. This is the Ellis our working group.

B

Maybe um Alistar, could you shut that door.

B

B

Ok, so again, this is the first meeting the first session of Dallas, our working group.

B

We left off at no well slide. So this is the note well from the the most current version.

A

B

Anybody need me to read the note well slide, you stop nodding your head.

B

Okay, so we're gonna move on to the agenda to these status, slides.

B

C

See there, okay, I'm gonna, try and go through these quick. We we had a very prolific third of the year and got through a lot of these are SCS published. I do have the one no SPF v2 extensions, that was actually a beer document, but the other ones all published.

C

Granted they most of them are pretty simple extensions, but it was nice. There's there's a thing there: it's not. There has nothing to do with Chinese food. The whining is, is the MSG that's MSD to next slide? Okay, so we have a lot of these.

C

We have the ton encapsulations giraffe, still waiting more than a year now and on the it uses, the Ayanna registry and the BGP document. There's a lot of bests and BGP documents, probably half dozen documents, depending on this, it's being presented tomorrow and IDR. Hopefully we can move forward. Oh, we also have the OSPF OSPF and OSPF III extensions and we're waiting on the inter up with LD P draft and the M POS data plane segment, routing drafts.

C

Those are both spring documents and I'm, hoping the former I think the former is almost done. The latter I'm not sure Interop, with LD P LD P, is missing next slide. Okay,.

C

The first one H bit support that's been waiting on the office. They promised me something this week.

D

So actually we have updated the graph, but we missed their deadline, so it will be done soon. So it's.

C

Often right now it opens up it.

D

C

Opens when the ITF starts okay, so.

D

C

D

C

Can update it and we can ping L borrow and let them know this comments. Eius eius extensions for now, we'll have all of our OS r documents or MPLS data plane segment routing will be once we satisfy. We got two of them on the RFC queue waiting for miss references with miss refs, and this one once we get past LRO's review, he just gave us comments in the last week or two we'll have them all done and we'll be ready to start on other the flooding and other documents.

C

We have these two yang models, their way down ad to review they're kind of big, but they've got they. They should be alright. They've gone through several yang doctor abuse and I just requested this cross address family publication. For that one excellent.

C

This is in working through a glass call and encourage everybody to review it. This is the more deterministic restart signaling for is is similar to what we have before SPF. So you can do like a pre-planned Reese. You can. You can request, restart graceful, restart procedures prior to restarting, and we believe these two are ready for a working grass call. We have the intent to do them.

C

They've been around quite a long time, there's at least for those bf one there's some implementation work, I, don't I don't know about is is I'm, not sure, but I know we have OSPF and next slide.

C

Okay, we're looking for both these two is is and OSPF the ELC giraffes show who's, not here, but I think Stefan's going to update these and we'll probably we actually have enough changes. We'll probably do another working group last call I haven't talked to the offers, but at that time we may think about combining them into one. Since we're going to do another working book last call anyway, next slide and flex algorithm.

C

There's some implementation, momentum, I, don't think we're ready for working to the last call yet, but it's it's just moving along where else it well. One thing I did I talked to the IDR chairs after the first IDR session, and especially for some of these simpler extensions they'd like to have us, allocate an Dianna code point for BGP LS and do it in the same draft. So you don't have you know for every extension in is, is and OSPF just like.

C

We, we combined some of the drafts with is, is and OSPF when they were really sitting exactly the same extension, just encoded two different way in the same in the same spirit, we'd also defined the bgp LS code point right away, and we got these two yang models for sr. Now that we've got these base, I think before we did anything. Those were just going at least wait till we get through the ad review on the bass yang models before we try and working group last qualities, but we're gonna do that shortly after that.

C

Alright next presentation, oh.

C

Yeah we've been pretty busy as far as discussions and we're gonna have updates on at least at least the first two of these graphs. These are the more significant ones. The other two are sort of protocol maintenance that we approved. One is one request across from the PCE working group. We already have PCE discovery just an extension on. It also discover the indication that the PCE server my at the moment, I can't remember the name that what is it PC? What yeah yeah yeah? Oh yeah, yeah?

C

They learn the md5, but I was thinking of the difference between the client and you call it the PCs. That's the client yeah yeah for the client to discover the server's security and that's it.

B

Yeah so I guess the sort of big thing that we've managed to do is get everyone to mostly agree to the resolution with the dynamic flooding. So.

A

That's a good say yes,.

B

Od I think your.

E

Good morning so I'm very pleased to report that we have accepted the dynamic flooding draft. As a working group document, we have.

B

There's no page.

E

Let's see I happen to show some friends some of our simulation results and they commented that they wanted to see a whole lot more of them, so have some of those to show you. Thank you. Mr. Scudder, we have two outstanding issues. We've already discussed a little bit on the mailing list. These are the question of how fast we add temporary additions to the flooding topology.

E

When we realize we've had partition and then also are we going to include lands in the flooding topology as an explicit part of the topology description, we've had that hashed out a bit on the mailing list, but have not come to consensus. We this week had a little lunch and arm wrestling match between the parties.

E

In having the discussion, we think we have come to rough agreement there, and we will return that discussion to the mailing list to achieve consensus after IETF on with the pretty pictures so just to show the flooding topology on some simple, dense graphs. This is k5 the complete graph on five nodes. The dotted lines show the links that are excluded from the flooding topology.

E

So you see that this is already winning about 50% next slide: okay 10! This is a full graph, a complete graph on 10 nodes. As you can see, this is already having wonderful effects right. Most of the links are no longer included, as we scale upwards next slide. This is K 160, 160 nodes and very Spartan next slide.

E

Some of you are interested in leaf spine topologies. This is a Lisa pint apology with eight spines and 200 leaves and, as you can see, it looks dense, but actually this is very sparse. This is like 95% of the links our block.

C

Is this flooding topology have two ways to get to everything all these all these simulations are one-way. Everything is by connected.

E

The diameter is constrained and also the degree of each node is constrained. So what that means here is that all the spines are equally loaded next slide.

E

We also were interested in looking at close to apologies. This is a three stage with 16 top nodes, 64, middles and 160 leaves at the bottom, as you can see, algorithm does all sorts of weird things, but turns out a beautiful picture. Okay, next slide, there are topologies where the algorithm doesn't do pretty things. This is an 8x8 grid, just a chessboard and, as you can see, the dotted lines are relatively few and far between this does not work very well. Why not? Well it's not a dense graph.

E

The problem that we're trying to solve is flooding on dense graphs. When you throw this on a graph, that's not dense, it doesn't help very much doesn't hurt, and that's actually more of the point for our testing is to show that the algorithm doesn't break anything, but it doesn't really help very much. Okay next slide.

E

So just to recap the two issues we have outstanding temporary flooding. So when we realize we need to add temporary flooding onto the the flooding topology because we have had a partition, then there are two opinions ones do we add as much stuff as and folks, some folks favor this, because it minimizes the convergence time we want to get the flooding topology back to covering everything as quickly as possible. That's certain!

E

So do we turn just turn on all the links and see what happens. Flipside is well. If we add on too many links, we can recreate a catastrophic collapse and obviously that's got infinite convergence time. So that's not good. So how do we do this? So we don't trigger that and therefore the conservative approach might be to add links very slowly again. We're gonna continue discussing this on the mailing list, but those are the two prevailing opinions.

B

So no one's asking for the goldilocks solution well.

E

Everybody wants both, of course, and nobody has proposed something that gives us both.

E

The second issue is putting pseudo nodes in the flooding topology. Currently, as the craft reads, you cannot describe a LAN in as being part of the flooding topology. This comes gives us some topological constraints. If we do have a flooding, topology that might include lands and area leader cannot describe it, then you might get a topology that is radically different than what the area leader intended and that could be a problem.

E

We I think we've come to the agreement that if LAN is in the flooding topology that all nodes should be flooding to and from that lamp selectively, flooding that gets really complicated really quickly.

E

So then, the two opinions that have been put forth on the mailing list: either we put all lands on the flooding topology, and this makes everything very, very simple or if we have too many lands that seems like that could be problematic.

E

So we need to be specific, and that's that allows us the the area leader to describe exactly what should and should not be on the topology. So again, we'll have that discussion continued on mailing list and that's all I have any questions.

E

Thank you very much.

F

To clear it fast enough in my old age year, dave allen from erickson.

F

Well, this speak up. Do you have any information on the diameter of the flooding topology relative to the type of graph? The.

E

Question is: do we have any information on the diameter of the flooding topology relative to the original graph, so that is algorithm specific in our implementation? Yes, we constrained the diameter. We definitely increase the diameter okay for a complete graph. The diameter originally is one as you can see the diameter in graphs. We generate much higher so that, of course, causes increased flooding time, but we do have a diameter constraint in there trying to minimize the diameter because we don't want it to go unbounded.

E

Okay, thank you. Ac.

C

Linda I got a I got a quick one here. I I definitely agree that you would not want to do anything on a land but flood. You know you know basically, because you have designated I mean a dr or it is it's gonna, be a good flooded to all the notes. You don't want to change your on a chain touch that, but wouldn't it be algorithm specific, just whether you you you made, you know how you prefer glands and how you didn't I, don't see why you'd need to maybe I, don't understand the problem.

C

I, don't see why you need to put all the lands on the flooding topology. If the algorithm didn't need to put.

E

Them all on so so the real question is whether we are allowed to specify lands in the signaling of the flooding apology. Okay, if you can't specify it, then no matter what your algorithm happens to do, there's no way to say so. Do we have the specificity in the actual description.

E

Any other questions I.

G

Just want to test okay.

E

This isn't my keys work.

E

Going once going twice done, thank you.

H

C

Think it's less right.

G

A

I

This is I this yes, but this is the alignment. Where can't see the whole slide.

I

Anyways, unless Ginsburg talking about the spine leaf draft of next slide, please so this is just a summary we've presented this before can run over overview of what this draft achieves. It's a modest extension to is, is so in spine later topologies, using these modest, modest extensions, you can get a great reduction in the amount of flooding.

I

Basically, what we do is in most cases we completely eliminate flooding to the leaves entirely. We also have some support for zero-touch provisioning or you can advertise your tier and just discover it.

I

We do have provisions to handle what you end up with. Basically, if it new leaf nodes is default routes to the spines, but in cases where spine notes don't have full connectivity to all of the leaves, we have provisions to get a subset of the more specific routes that are required so that we don't black hole things and we have hooks so that extensions like the flooding topology that Tony was just talking about.

I

We can advertise that the the links to the leaves are not being used for flooding, so the algorithm can can know what those links are and just basically take them out of the calculation of the flooding topology next slide.

I

So what's happened since the previous version. We became a working group document. We had some comments about some of the information that we were allowing to be sent in homes. We've simplified that and split it. We had one TLV. Now we have two different tlvs I'll talk about that. A little more and we've reintroduced support some limited support for a connection leaf to leaf connections. Next slide.

B

So when this was actually a long time ago, you had this leaf Khalif support and it was the one place. It kind of scared me where there was possibilities for like loops. It seemed like right: did you guys I mean, do you think you addressed? Did you see that as well, and do you think you addressed it? Yes,.

I

But I'll talk abouts more, so you can ask more a more specific question. Okay, so we have a spying leaf TLV in the hello which does a couple of things one. It allows you to advertise your tier if you are able to discover it and there's a bit that just says the tier field is valid and if that gets not set, whatever values in there is ignored, and then we have two flags, one of which is sent by the leaf.

I

Node that says, hey I would I would like to be part of the reduce flooding, which means I. Don't want my spy known neighbors to flood LSPs to me and we have an AR bit that's sent by the spy notes that indicates that they can be used as a default gateway. This TLV previously had additional information which we moved into a separate TLV. So now this is the information. That's the only information in our extensions, that's sent in halls.

I

Next slide, we created a new TLV, which we call the leaf set TLV, and this is going to be sent in Circuit scope, Dallas Peas, as defined by RFC 7356, and there are currently two sub tlvs that we've defined associated with this TLV. We have a leaf neighbor's sub TOB, which is sent by the spine nodes, and that indicates the set of leaf nodes to which this by known, has connectivity. This information is useful to the leaf nodes.

I

They could compare the set of leaf node neighbors that each spine owned, advertises and therefore detect that og this this by known, neighbor that I might be using as default gateway, doesn't actually have reach ability to the full set of leaf nodes. Next slide.

I

The second sub TLD and in the leaf set TLV, is sent by the leaf nodes. So, in the case, I was just talking about where the leaf node discovers that hey there's a spy. Node I was using him as a default gateway, but he doesn't seem to have full connectivity to all the nodes. The spine node can send a request or the leaf node excuse me can send a request to the spine node. To said, could you pretty, please send me prefix reach ability information associated with this set of leaf nodes?

I

So it's just a list of the system IDs of the leaf nodes which he's retrieved from the sub TLD that we showed on the previous slide.

I

The spine node will then respond by sending and yet again in the circuit, scoped osp's he'll simply send the standard prefix for each ability, tlvs such as 135 and 236 the leaf node on request and say: okay, here's you know here are the prefixes that are associated with that leaf node and that allows the leaf node to install more specific routes to those destinations next level. Okay, as Chris's question highlighted in in early versions of the draft, we had connections between the leaf nodes. There were some issues raised with that.

I

We took it out, but there are deployment cases where people would like to be able to send traffic direct from leaf to leaf. So we put this back in, but.

I

I think I've jumped ahead of myself here.

I

Yeah yeah, sorry, you got me.

J

K

Was just thinking.

J

I

About to go to that I'm sorry back back up, let me get this light because that's all so we we've introduced to bits one of them is- is new to this version of the draft that's associated with an existing TLD. The link attribute sub TLV that was defined by RFC 50:29, the the I've listed here, all the bits that are including the ones that are currently defined so there's a local protection and an excluded from local protection.

I

Those were defined many years ago, the two new bits, one of them, is sent by the spines that says: hey I am connected to some leaf nodes that want to be excluded from flooding.

I

You know, and these are the link- this is the one of those links and that tells an extension like the flooding topology, the optimized flooding topology. That says, hey. You don't need to consider this link just part of your flooding. Topology. That's been defined for some time in versions of the draft. The new bit that we added in in this new version of the draft is sent by the leaf nodes, and this bit just simply indicates I am connected to at least one spine. Note and you'll see how we use that.

I

Now you can go to the next slide. So again we we put back in the ability to to support leaf to leaf connections, we're recommending that you only have one leaf neighbor, because there are some consequences of having many largely. It means you're going to increase flooding unnecessarily one things we want to do with the lease we're trying to keep the leaf implementation fairly simple, so we're not proposing that the leaf note do any kind of special logic associated with flooding.

I

So if you now connect, if the leaf node is not gonna doesn't have any leaf, node neighbors, he simply sends his own LSPs to the spy known as heat or Moyer would do. But now, if he has a leaf, neighbor he's going to get the LS piece from that leaf neighbor. Unless we define some special rules in this case.

I

That he's also going to send those LS B's to the spine, so the spines not going to get in this case buying one, for example, would get LS B's from Leafs one both from leaf one and from leaf two. Obviously, you start having lots of leaf. Neighbors you've increased the amount of flooding, so we're recommending that you limit this to one leaf neighbor, which I think from a deployment standpoint meets the the common deployment cases the that there are two modes that the leaf to leaf connection can be used in.

I

We really only want if you only want to use the leaf to leaf connection for local traffic, then the leaf node will set the overload bit in its LSP, which tells the spy known do not use me for transit to any of my other neighbors and in particular the other my leaf neighbor.

I

If you want to allow transit traffic in the case where, let's say I'm, the leaf, node I got isolated from all of the other spine nodes. So the only way now for spine node to get traffic delivered to me is to go through another leaf node. So in this case, you don't want the over a little bit to be set, but you want this to be used as the link of last resort. So you set the hi metric, we're recommending max metric 2, and this makes this the link of last resort I.

I

Think that's it or yeah. So that's the update and we welcome comments.

B

So I think that the earlier issue I had to look. It was almost two years ago. It was like, if you had, you would like defaulting over to the leaf, but then you could have a better metric backer. It was something weird like that: I guess.

I

B

I considered that I'd.

I

Have to go back to the Russians, but I think I, don't think we ever talked about setting the overload bit before I think that addresses that problem.

B

In it, and so the over this would be for both leaves, so everything would be configured in the same mode. Correct yeah,.

C

So what what what I I guess? I I missed it that there was this biggest thing update. I haven't read the update! Sorry!

C

So the overload bit when a leaf gets isolated.

C

The other leaf would have to reach the leaf that still connected would have to reset over a little bit yeah.

I

This is not meant to be a dynamic setting. This is like how do I want to use this link if I only.

J

Want to use it.

I

For local traffic, then.

D

I

Overload bit if I want to use this as link of last resort in case isolated.

C

Okay- okay, oh but you oh I, see I, see I, understand now. I thought this was, it would change. Okay makes more sense, sounds ooh.

C

How many have read the update.

C

About know about or I advise everybody to to read it this. This has got a little more complex than it was, but not too much more, but I'd advise everybody, including myself, to read it. Yeah.

B

I mean if you it's always fun, to find loops right, so they might be hiding here. Still the.

C

Go go okay, bounty.

C

What one reason we adopted? This is because it seemed like a limit. It seemed to address data centers and it was a lot simpler than a generic flooding. We said, okay, we can. We can. We can do this and we can do something more more generic, so I'm hoping it's not getting too complex SID when she cleared up the thing of the leaf leak being a static configuration makes it thanks.

I

Okay, this draft was introduced in Bangkok and I'll just be reporting on the updates. I think they from the biggest news or most welcome change for me is we got some additional authors next slide.

I

So what were the the motivation for this largely had to do with we've seen in the field, some interoperability issues in how implementations handle tlvs, which are on either unrecognized or disallowed or incorrectly formatted?

I

When we had inconsistent behavior where osp's some implementations would discard LS B's some little implications wouldn't- and you end up with link state databases that are inconsistent on routers in the network, which really leaves the network in a broken state.

I

There's been enhancements a few years ago in terms of how purges are handled, and these have backwards compatibility issues and that played into some of the stars we've seen in the field as well as far as interoperability problems. So those were the major motivations next slide. Okay, what's changed again, additional authors have been added in the course of reviewing the draft with the new authors we discovered and I in a registry issue, so we're addressing that and we've added a recommendation about controlling behaviors that are not backwards, compatible next slide.

I

So the registry issue RFC 62-38,.

I

Sis purge origination TLV so that you could identify the source of a purge, which is a very important thing to be able to do in troubleshooting some problems in networks. The text in the draft was absolutely correct. It said this TLV should be found in all bridges and must not be sent in an LS, be basically a non purged LSP, an LSP with a nonzero remaining lifetime.

I

Unfortunately, the Ino section- and this got put into the actual INR registry, the the flag for the LSP- that is the non Burke's Dallas piece got set to yes and it should have been no, so we're correcting that. So again, the text in the RFC was absolutely correct. It's just the the setting of the flag in the registry was not next slide.

I

There was also discussion. We thought it would be prudent to recommend that when you have transitions to new behaviors that are not backwards, compatible, that we recommend that implementations put some control zone as to when to enable that one example, not the only example, but one example of that has to do with the the introduction of the purge origination TLV. If you look at the cryptographic authentication as defined in fifty three or four and 5310, it was very strict. It said the only TLV you can have an approach.

I

If you have cryptographic cryptographic authentication is the authentication TLV. When we introduced Pio I. That obviously meant there was at least one additional T viii that could legitimately be found in a purge, so implementations which are following 5304 strictly as they should would then reject purge that had a Pio I. So you need to be careful as to when you enable this behavior. If you have cryptographic, that is the use of the purge TLV in the presence of cryptographic authentication.

I

So what we've added to the drafts is just the recommendation that says in such cases it's prudent for implementations to provide controls for when to enable this next slide. So I have to say that this has been amazingly enough and quite surprising to me this has been the most popular draft I've ever written whatever that says, so, we've gotten a lot of support from this there's. Also those we published yesterday. We actually published a update to this.

I

Based on the comments we have received from Bruno, it's mostly using more clear language, no real edition in terms of the substance of the draft, but hopefully it's it's more clear. So we think this is ready for working group. Adoption.

B

I

J

B

B

Yes, okay, thanks I mean we'll ask on the list if anybody objects as well, but have an obviously.

L

J

Okay, so I'm beer from Cisco, so I'm going to just give a quick update on the SRB 6i sigh. This extension draft.

J

So we just added a single new flag in the locator TOB, which basically indicates that the locator is users at any cost. One. One reason to do this because there are applications where you don't want to use these seats from the locator, which isn't any cost one, for example, for a PA or favor. You really want to enforce the traffic over a certain note. So that's the use case.

J

That's the B to be added thanks, fine and we also updated the table in the draft which reference to the supported, end point behaviors, which are advertised by esaias. It might choose the latest network programming draft and it also includes the endpoint behavior identifier. It's just for clarity, so you don't need to go and look in other drafts would be what the identifiers are so other than that the the draft is stable. There are implementations you can go to next slide.

J

Please there are multiple implementations available, even working together, so I think this draft is ready for the working group adoption. If there are any questions, please feel free.

H

Yeah, like I just Alaska, how.

C

Many people have read the draft.

C

How many people were sort of following the spring network programming that that adoptions about halfway through there's some there's a lot of support in some discussion about other issues, but I think we're going to ask for an adoption call on this one, especially if it? If the immediately after the network programming is adopted in spring, we were sort of waiting for it. They asked for adoption last in a Bangkok, but we were we delayed until the net. At least the network programming call for adoption.

C

J

Okay, so the next one is the OSP v3 extension for for beer next slide. So we have RFC eight four, four four, which describes the OSP v2 extension for beer with an TLS encapsulation. We need the same work to be done in OSP v3. So this is the draft that deals with that. The flooding scope and all the machinery in a protocol is exactly the same as in the RFC. Eight four, four four.

J

So next slide, please so just to recap: what.

J

So what we define, we defined the beer sub theory which is carried within the prefix, so it uses the new II, inter and inter area prefix OS ice to distribute the beer. Specific information I mean the fields in the inner circle. We are exactly the same I'm not going to repeat them as India's PB, two extension.

J

This is a sub theory of the beer. The beer TLV, which carries the MPLS specific information for beer. So again, I mean the fields in the in the sub TLB match is the one in your spirit too, so this has been presented in the beer working group, I think they're going to own the document, if I'm not mistaken, so the reduction in request is basically going to be a I'm presenting here because it's an extension to the ITP. So if you guys have any concerns, just let me know- and we can work it out so.

C

When we chartered beer they wanted to go on a fast track and on all the documents, and we agreed that they could own these. These sauce extensions in beer, so it makes sense since since OSPF and v2 and is is are in beer. It makes sense for this one to go there as well, especially since this is just using the extended LS ace. The reason we didn't do, OSPF v3 before was because the extended lsas hadn't been published.

C

Yet now that it's published implementations for going forward and and finishing that work, that's correct, so I I mean it'd, be nice if I mean it'd be good, especially if oh s, PF implementers and people who debug and deploy OSPF b3 networks would review this.

I

Mr. Michael S Gilbert so I'm just asking does that mean there really is no working group adoption request here? No, it's in a in a bi working group. That's correct!.

J

J

By an attack, yes,.

J

Okay, so the last one is the extension for OSPF to advertise the admin tax. So it's not working anymore. Okay, all right! So a little bit of a history in Nice, BF, v2 and v3. We had a way to send attack the admin tag with the prefix, but this was only limited to certain prefixes, namely the external and NSSA prefixes. We didn't have a way to advertise admin tag with into our inter area prefix, and we were also limited to a single one. Every fix I mean we all know.

J

We have different use cases for tags. We use them for a distribution for a prefix, prioritization and various use cases for this.

J

So what we actually are proposing is that we are adding new tag: sub TLB for either the extended prefix TLB in OS, p, p2 or and into our inter area or external. The prefix GL is in in the extended OS baby's real essays. What we also added is the tags for the links and whether there is something that we want to do is up to the discussion, because we have the si oh geez, where we can actually advertise similar 32-bit values for each link.

J

It's up to the working group to decide whether we want to do it for prefix for links as well. But the draft itself proposes the extension to be able to associate the admin tag which the prefix or link.

L

J

Right so I mean the deal is pretty simple: it's a bunch of 32-bit administered attacks in a sub theory, so it's very simple we've seen this before.

J

So the draft also says about what how we are going to propagate the admin tags between the between the areas and during the translation. It also says how to behave during the summarization, where we are not going to advertise.

J

The tags of the component routes go to the next place, and it also says that if you have a tag associated with the external or an SSA LSA in the you know old-fashioned way, we prefer that because we want to be backward compatible, and it also goes into the discussion that there can be multiple tags associated now is the prefix etc. So what what the behavior? What oil behaviors that we can use so I mean natural. This is a very simple and natural extension. We want to have the possibility.

J

It's mainly I mean the way I look at. It is for the entire inter area prefixes to be able to tag them, and you know use this. I mean we have the similar capability nice eyes. So I guess it makes a lot of sense to to adaptation and move forward.

I

What's Ginsburg um I'll ask a loaded question here and we made a conscious decision not to support 64-bit tags I.

C

Put it in the appendix appendix of it, because the I found no implementation of 64 bit pegs in eius eius I asked I asked a lot of people and nobody knew why yeah.

I

I'm, complete agreement with that I just wanted to verify that we've consciously made that decision.

K

Stephanie Costa for orange, you were talking about adding tags to links. What was the use case? You were targeting to that. You pointed s energy, but we have also admin hooks which could be.

J

We didn't have any particular use case. We just thought you know if we are adding this, whether it makes sense again, I don't have a strong opinion. We put it there, we can remove it, people think there's no use case for it. I don't really know yeah.

K

I think we have sufficient mechanism today to tag links fair.

J

K

C

A co-author I would agree as well. This was I did this draft a long time ago. There was no burning requirement for it and we had full working group agendas and things that we needed to get in front of the working groups, so we kind of delayed it. We had to session said: okay, we now's the time it so there's nothing too contentious until tomorrow, and so we put that we put it on the agenda. We said: okay, let's try and socialize it, but I agree. Now now we did so.

C

We had not just with this this. This predated our whole discussion of attributes. Okay,.

E

C

That's the link, tag, I, think I. Think I think we can take it out. I think it's captain, as he's known as in the IDR working group. Hopefully I won't get in trouble for that.

M

Hi Kate ontological Cisco, so this is an update on the OSPF reverse metric draft. Just a recap: it was presented in London. It was just named differently back then, and we have equivalent functionality in is is already there. Also. We also have a SP of two part metric draft, which covers kind of similar capable, or at least can be used for this use cases for broadcast LAN.

M

So what is draft essentially does is brings this capability, for you know, point-to-point links and other types reminder on water draft. Is it enables OSPF, router and septa cable for both v2 and v3 to signal to its neighbor, the reverse matrix? So it's a metric that a neighbor should use towards the link to this router, and this is done in a link-local signaling mechanism using the LLS block in hello messages when the neighbor receives in this case, r2 receives the reverse matrix signaling. Then it may use that value or it's a.

M

We have support for offset as well as value in its router, a let us say towards r1. So this mechanism is link-local, so it works. It's really between routers on a link and it's it's it's kind of transparent to other routers in the network.

M

So for this we have introduced the reverse metric DL reverse metric TLV. What's the new update in this draft is we have also included the reverse key metric TLV, because this was something that was not covered and there was no support for I mean we had missed multi topology ID, which was not there in the previous version. So that's the other update, that's you know been introduced.

M

Apart from that, there is really no significant change in the document, except for some editorial updates.

M

You know, which was pointed by reviews, and so on so thing so look for working group. Adoption of this draft at this point.

C

N

C

How many have read the draft.

L

C

Yeah, don't count of you, you have.

C

Yeah we'll take well we'll discuss it a little bit on the list, the use cases I know. One of the use cases is the same use case that the large packets are in VF d, l2 VPN. Where that you know where you're you don't know the characteristics of the underlying l2. Yes,.

I

C

O

C

One of the use cases and that's the same yeah same motivation.

B

So does anybody object to possibly taking those Ana's work? No, there was nobody.

M

So this this one is OSPF. Introducing PFD strictmode just had a presentation of this earlier today in the PFD working group, and this is something that we have in multiple implementations already. So we are. What we are trying to bring out here is to define it more formally, let us say and to see how it helps in you know some of the Interop issues and concentration.

M

So the problem statement here is that PFD is being used by OSPF for detecting faults in the forwarding plane and primarily detecting it fast and bringing down the adjacency.

M

However, a PFD router does not know as part of its signaling whether its neighbor has support for PFD and as a result of this, the BFD OSPF adjacency is brought up. Without you know, considering the weather, the BFD session is brought up or not I mean it's brought up independently.

M

Now, in some scenarios we have seen or observed issues where the SPF adjacency may come up, but the PFD may not come up, even though PFD is enable on both sides of the link, and this could be because of some problem in the underlying path. Now this you know could be for written various reasons, including transport lossy links.

M

You know, degraded links so on so forth, and what this results in is, even though the OSP of adjacency may come up and we advertise it in routing the traffic overhead would you know get affected as well as in case of lossy links? You know you may suddenly find sometimes OSPF adjacency is also flapping, so it's a term that is introduced in the network.

M

So what the draft proposes is really to enable OSPF router to signal to its neighbor, that you know it's AIT's running BFD and be that it does not want to bring up the OSPF adjacency unless the PFD session is up between them, so which means that the BFD has verified the bi-directional connectivity and only post that we try to bring up the OSPF adjacency, and this is what we are referring to as PFD strictmode in this document.

M

So this there is a similar extension in ISS 6213 and it's kind of similar functionality that we are proving. So how are we doing it? We have in the OSPF hello messages. We have the limp local signaling block and in there we have a TLB where which allows it's called LS, extended option and fields. Flags field which allows routers on the link to indicate capability to each other and where we've introduced a B bit there and this B bit indicates you know, supports or capability or, let's say, interest to operate in bf District mode. Now.

M

The PFD session establishment, when, when the routers two routers detect each other, they are supporting this bf district. More then, as soon as a new neighbor is detected, PFD session is requested immediately and the keychain key thing is. There is some we're trying to clarify in how to do this in the fitted into the OSPF neighbor as possum, and the proposal is that the neighbor is held in the init state until the BFD session is up between them.

M

What that also means is that we do not. The router does not include the neighbor IP address in its own hello until the BRP session is that this is essentially will block the adjacency of the neighbors FSM to move into you know to where next art so moment of BFD session is up, include the hello neighbor address in the hello and then the FSM proceeds as exists today. So there is no change after that.

M

From backward compatibility aspects, this mode is going to get employed or come into action only when the two neighbors agree- or you know, exchange this capability- and this is only I mean if it's not there than though SP of neighbor FSM goes like like existent today, and the change only changes in this initial bring up. So it's basically the transition from init state onwards. The rest of the neighbor of SM is not is unchanged.

M

There is also no change in the way BFD is used to you know, bring down an OSP of adjacency handing of bfk down events. All of that, no nothing is changed from that perspective, so a little more details on the bf be part. So this is again only changing. Only changes are in the initial bring up, there's, also more details and text in the draft.

M

We try to cover scenarios where this capability or this option is turned on for an adjacency which is already up and there the proposal is that we do not disturb and adjacency thats already up. It just continues, and you know, removal of BFD or the PRB strictmode also does not disrupt adjacency. That's already up so next steps. We are aware that multiple implementations have this kind of a feature support already and it's the way it's been done is the kind of explicit configuration support, but we've had some cases within drop.

M

It's not really clear at what state in the neighbor of SM, let's say: implementation should all the neighbor and how it should go about it. So it also makes troubleshooting difficult in that aspect. So we are looking to trying to see a working group was interested in standardizing this and would appreciate feedback. You know and commit.

B

So you found incompatibilities out there with which I understand that there is no standard. Yes,.

M

So I mean the key aspect of improv issues is where the neighbor FSM is held by an implementation until the B of T is brought.

B

Up is it actually functional.

M

So that two parts of it one is that we don't know whether the neighbor is strict mode enable so the first way to get working between, let's say to implementation, is that both have this explicit configuration and then you know they bring it up now, in a case like a LAN, for example, where there are you know, you may want to do it with between two routers, but not with the third one is not capable that's a provisioning aspect, then, within the bring up as well when the BFD session is every session cannot be brought up due to some errors or whatever we see the neighbor FSMs.

M

We do not even see a neighbor, let's say on one router and we see it on a unit or a two-way state or something it becomes difficult to figure out what's happening or where this is that so.

B

I guess where I was going with this, is it I mean it's interesting, you've already discovered this? Do you cover these cases like it might be interesting for an appendix, or you know, for deployment right like if this is deployed? This is how well interact with these various. You know non the interoperating, and then these are the results that we currently have with these. You know non-specified non interoperating things.

M

It's not there in the draft, but what provided some Texas to describe an operation in kind of like operational consideration, what all information should be shown or how? What logs install should be done to reflect the state? And you know if the neighbor is not going beyond in it? Why is it not going yeah.

B

I mean no such thing is it's interesting. It would probably be interesting to list the Interop issues. You've found that you'll be fixing sure.

M

B

Doesn't have a very extensive okay.

M

And I mean many look forward to inputs from other implementation, not sure if there are implementations which are doing this differently, but we would like to get feedback on that. So.

C

Let me understand it, so if you get a hello and it doesn't have the strict bit set, you just don't use PFD as a precondition and just yes'm it and just goes okay and then, if the bit flips anytime once the session is, is passed Annette you just ignore it. You just keep point. Yes,.

L

C

I mean that's kind of a subtle that naturally falls out nice and the implementation, that's where it would be really nice to talk to some other. You know get some emitters that want to do this to collaborate and make sure yes, yes, so.

M

Definitely need no feedback and inputs. There.

C

Okay thanks: we.

G

A

Hisoka, we don't know if it's gonna work, we have to see, we don't I, don't know why.

L

P

Yeah, okay, it works so on one more from following today, I'm going to talk about this issue beautiful at introduction. Basically I just talked about the updates in this version. So in this version we remove centralize the fatality reduction and then we also updated distributed faladi reduction to get instructions from the leaders because of this remove and then we added a scheduler and consistence check.

P

So, firstly, we talked about the scheduling so scheduling for flooding, topology computation. So there's a new RFC talking about a skill for talking about a scheduling for SPF.

P

So right now for some network we have multiple schedulers I mean yeah Nodoka. Normally we have our routers from multiple vendors, so the wrong hood from one vendor may use a one type of scheduling for SPF and some of routers from a defender will use another schedulers for SPF. So the issue is that using different the schedulers for SPF, we are create more routing moves than using a same scheduler. So this is a toka instructor in forgive hell in this view, RFC's.

P

So as we know so that the suggest the best practice is that we configure similar timers are water routers. So in this case we want to have SP to be triggered at almost at the same time, but sometimes is impossible.

P

So here my example is that for consecutive SPF executions, if we have two different schedulers, that is almost impossible to have SPF on water, knows to be triggered at the same time. So here we just have two two examples have two schedulers so once the gradual is that we just the schedule SPF in constant delays, for example, first SPF delay, 200 seconds, 200 meter, second and then second consecutive race, 200, milliseconds and then serve and so on.

P

So this is a constant delays, so another circuit law is that we have initial delay for the first one and then for the consecutive rain, and then we use a whole whole lot of time, for example, is maybe 100 milliseconds and then the next one, the whole time will be double the first of the whole and therefore we have an I'm just a latter run and then the delay time will be double the first of the delay.

P

So if we have these two kind of schedulers, so is it almost impossible to configure one over time to have those SPF to be triggered at the same time? So the this new RFC, in fact that we have was used same circuit less, but the reality is that for those schedule it for SPF we already implement. So we we have no way to at least no way to do that right now, but for secure him for a lot in towards computation. So right now we have a is a good point.

P

We could is right for and we needed to have use the same schedulers for scheduling the flooding topology computations. We were yes.

C

I might be in a menorah I. Don't agree that you can prepare FTC and SPF I, don't think they're the same thing I mean I, don't think they require. Ftc requires a scheduler or like some ask as because you don't update ribs and fibs and yeah. It's.

N

C

Internal to the protocol- and it can be done very quick, I, don't but yeah.

C

P

A good question I sing about that a lot, because if we use different schedulers, so the flow I, don't I won't do it different right.

C

Something you need a scheduler for this. You.

P

C

Let's do it possible yeah.

P

That's another way: I think I may be the batter. I have a scheduler and there was a control because we can control the timer Paula get faster.

J

Can I it's better from Cisco I completely agree with I see you don't need any scheduler here.

P

Yeah because I use the batter to have a scheduler, at least because if we have a consecutive of computations and then they may have some issues yeah so with a scheduler and then we can have control, so you would control you can compute those time if we're smaller and then looks like is a we can cheat with that. One right, first ask so.

B

Since the cane has been opened, I don't like this either, but my dislike of this is we've been able I know, there's an RFC there, but we've been doing is eyes for a really long time without standardizing and unwire POVs to specify one timer should fire. This is this seems like a big overreach and it just doesn't need to be specified. I, there's other things that I like in this trap. Wow. This is not one that says a working person.

P

So another I saw because we right now this transfer is focused on YouTube the flight interaction. So for this to be the final action, we need a get instructions from the error leaders, so we need a so after operator configure the distributive flatten reduction. Then Evernote master receive the leader staff at LV, so in this leaders at supper, TV we're happy indication which algorithm we have used and also should be indication of what distributed mode and then so. We also should have received those kind of parameters for the schedulers evil.

P

Those configuration is done on the leader.

P

So the last one is a about a lot in poverty, consistencies check, so so for a lot in her body, because flat entomology is computed by Evernote. So one flight, already computed by one node so must be, is the same as the one computed by a master node. So if were to fall out in trouble yet different, and then the inconsistency occurs, so we need to have some way to detect this consistency and handle it accordingly.

P

So those so here we just proposed a very simple way: we just define new beat in the hollow, extend the hollow we caught a flattened, hopper, a bit or a link so for each end of the mink each load, each internal order of link. So when that this node have a line table change, we can talk this link. We just change that a pata Pete.

P

So if two people are the same and then regarding to this link, the following property is consistent if they are different and then we force for given time people in the for keep in high and then we think that this a polite ontology is not consistent. Regarding to this link, so we can warning and then, on the other side to side, maybe if one side the thing is not not on the kavagi, maybe we just temporarily assume that were under an apology. That's the I.

O

Think that's or um maybe yeah I could provide some color and that I'm sorry I'm sue hairs.

O

Most people know me as a IDR chair: that's not what I'm proposing right now but that'll give you a place to find my email so.

O

Two things on this one just to provide some color in in some research I've done on why this problem might be useful.

O

One of the deployments for IDPs is in IP ran technology. Some of the IP ran technology has been sold, places and I. Don't want to be pejorative because sometimes the for any particular place in the world. Sometimes the US has brownouts and so, as they have brownouts some of the links, transceivers get drowned out.

O

Unexpectedly and so I don't know if this is going to help that I don't know if it's going to hurt, but it is a problem that you know the research shows if you're working on convergence- and you don't know if, if things are working right, you make the IGP signal something more to say that I've got the right to apology or warn you and that that may help you in the cases where the the link connectivity, you may try be a fee.

O

You know Kate I'm, sorry Kate on, for my mispronunciations has this other BFD I'm, just I'm, trying to give color and why some of these problems are are important. Based on some research, I was asked to do into some customer problems that that's comment. One I hope that may help at least that's.

O

Why I understand the need for some of the last couple presentations because it matches some of the problems that I've were reported and I was asked to look at a GP convergence simulations based on the long term, work that Angus lose enough and other people have done in a GP convergence and how to look at it in simulations I suspect, Tony simulation has that anyway, just a side comment, I, hope you don't mind me making that comment where it might be a boat window.

B

I think everyone's in violent agreement with about this yeah.

O

B

O

Have any arguments? Okay, that's great and.

C

What's the one thing we'd ask: does your least what you looked into for this topology? Does it support the mechanisms in this draft the scheduler and no.

O

No mine is strictly into the problem. The the draft that I put out is strictly the problem because I wanted to III. The first thing was: do the problem? I don't know if way. Most simulation has gone into this. With that thing, I I won't comment. There are two groups doing research in different solutions, so you may ask way mo and some of his team on that question rather than me I.

O

My first was to do a purely theoretical and then look at some improvements and and do some simulation based on aggregation, so I'll point back to way mo and other places that that's just dodging, because I didn't do. That particular work. Does that it then I was I clear enough and my caveat to say the theoretical points that it would that that, if you don't have consistency, but that's that's a general no well known problem back to 2000 or 1995, because we used to have early days of internet. We used to have the same problem.

O

1997 we had blackout, half half done links people our Father. Second question is for ACI. If I've ended this topic, okay, so most open-source implementations that I've worked with and I'll just say, open source and other code bases I've worked with whether you have a scheduler or not your code. When you look at it has an inherent ratio of scheduling for sending out is, is when you said I, don't think there should be a scheduler. Did you really mean yeah? Did you really?

O

Could you give a little color on that, because that doesn't really fit again the theoretical work from the stuff for it yeah they always assume. You have some sort of range well he's talking about the.

C

Distributed algorithm right so that would imply I think the best schedule. There is no schedule err at all. That's my opinion for that.

N

Because I think I.

C

Think I think that that is a very simple computation and the the problem you really have is the one that Tony was talking about right with what what you do in the transition periods, whether you do a lot or you try and do just the union of the old and the new and do a little. Those are those are that's more. It isn't.

O

C

That than the scheduling, yeah.

O

It is, it is in the transition, but the self synchronicity and jitter we once had was to deal with the fact that if you have no scheduler, you can get into this synchronicity problem.

B

So maybe I think maybe sue you because AC said none. My I was saying something different than yes.

N

Yes, like what.

B

I was saying, was I, don't think this should be standardized I'm, not saying listen. If you want to put scheduling in I mean and we've got Dec it decades of experience right I mean we have. We know how to we have ideas about back off, timers and- and it's worked just fine for decades- for that not to be standardized right.

B

It's not that I'm I'm, not saying you know if your implementation needs based on you know, I mean this is an implementation thing right like if, if it has a if it's cooperatively, multitasks or who knows what right like you, you might have a better timer set up for, for that particular thing to get the the behavior that you're looking for that I think you're. Alright,.

O

B

I shouldn't be on the wire okay.

P

This is not on a wire it's just for so we assume each note or Evernote use the same schedule that there's no Wi-Fi.

B

But if you're standardizing what to use it's on the wire yeah.

P

This one just the option, this one.

B

P

Is option? That's.

B

O

I, don't I don't want to take too much of the working time, but one of the reason we early on put and I'm sure the the experts like listen, you put jitter and this stuff is to get rid of cell synchronicity and we're back into redoing some of the algorithm, and you know I'm not seeing the same topic. We reiterating and I'm just wondering why about for for Tony's algorithm? If, if there's a you know, are we gonna get into the big Q calculation sending out big bursts of stuff?

O

Or do we just not have the problem? Because our interfaces are so faster I.

B

Think this is an interesting thing to talk about right I mean we are under we're working on it right and I think it's interesting to talk about. You know when links are added when they're not added and all of this right but I. Just when you actually calculate a flooding. Topology could be a part of that discussion. I just don't see why we have to I mean if we want to be agile right, you don't want to be specifying this stuff right.

B

O

Island wire protocol.

B

O

Would be lovely if we didn't have to specify anything and then less is more in in much of the thing. I think the questions again. The questions behind some of these desires are what I'd like to see us discuss in a revised thing, because we had the problem. In the past we had the problem self synchronous. So as we change these floodings, are we going to get into the same problem? How are we going to handle? You know most of the.

O

If our art is only you, if you talk to Lee and there are people, but you guys are wanting to do with some of this as well. They only take care single link. Failure tomorrow, I'll show you where we have multiple in failures that are rolling blackouts. So just just a call based on some of what he's doing toward the problem behind it.

P

So I would like to request for options for this one because for distributor, faladi reduction, and then we have discussing a modest for a long time and so.

B

I have a chair comment. um You know we had a lot of back-and-forth and we were trying to figure out where things are going and how to move forward, and perhaps something I think maybe got lost along the way. This my expectation from the outcome of all of our discussions was that this was going to be primarily. Your draft was primarily going to be a specification of a standardized distributed algorithm and what this looks. That's now in its in your appendix of your document.

B

It's not normative and that this instead is talking more about I, think kind of a generic flooding thing right. I mean a generic dynamic floating thing, for example, I actually I like your FT bits. So if you want to go that, there's also think.

J

B

Is this is calling out, you know possible, miss configurations or problems in the network? This is very valuable information for an operator, okay,.

J

B

This is work, I, think that you should be working with. You know on our now working group adopted document right I mean this should go into the generic signaling signaling. That something is broken is a generally useful thing right. So don't you think that this should go in the in the dynamic flooding? No.

P

B

Specific to distribute to your distributed algorithm, yeah.

P

That's good question because of what distributed algorithm Evernote will compute a lot in topology right. No.

B

I your distributed algorithm. That's generally,.

P

B

The the working group document that we adopted right covers is about signaling, either a centralized, flooding topology, or it's also for signaling the area leader and the distribute algorithm number. That is the generic document that we're going to use right, yeah, that's what this was supposed to be about a concrete distributed, algorithm right if we're gonna be monitoring this.

B

In other words, this is the wrong place, or this is what I think I'm trying to say, because we don't, we don't want it's a working group document now, but Tony's draft that we had dropped adopted right is is the framework upon which centralized and distributed is built on right going forward. We have distributed, algorithms need to be standardized, centralized owns, so that's that branch is done, but we still have to work on distributed.

B

Algorithms, that's where the I think that's what I thought was gonna come out of your revised draft and- and things like recognizing, that things are broken, should I think be a more generally. So it's a generally useful thing right. Why should it just be your algorithm of benefits, yeah.

P

That's good question, so I wanna clarify this one, so you mention that is stupid. One so will receive the instructions from the leaders so I already described here. So every node will master receive instructions from the leader indicated. So.

C

There could be broke me, I mean you, don't expect it to be broken in either the centralized distributor its distributed no case. That's why this is good to determine in either case you know, because if somebody could have trouble, they could not be receiving and installing that, in some situations and and installing the the centralized topology correctly I mean it just just like the distributed, could could not work. I mean both could not work, you don't you, you expect it to work all the time and that's.

P

Why I think generally applicable.

C

P

I think needs more more cases of artistry what kind of this case, and then you wonder, generalize and how either did you realize? Oh.

B

P

Got an idea, but is most this.

B

Is supposed to be about an augur you're not supposed to be? We want the draft we adopted to talk about, centralized and distributed right. We don't want to. We don't want I think that there was definitely this, and maybe my fault and I will take this, because I think I was originally talking about moving distributed out of the thing, and that was not where we landed right.

B

Where we landed was we have a general framework document with sig how to signal the information, and then we were going to have distributed algorithms that were standardized outside of that and I think when at first, when we were first talking about it on the mailing list, it was being called the centralized draft and the distributed draft, and that's.

N

B

The confusion is, but that's not where we ended up right, because, because the work we adopted up front in order to move forward covers both cases right say, covers signaling first centralized and distributed so things like this, like the FT bit, not this one with the FT bit I mean this is this is generally useful. It should just go into the working groups document that covers centralizing and distributed signaling right, because this is signaling in a generic way about distributed out, distributed, flooded, right, yeah.

P

This is a because of using the email. You just ask her: we removed a centralized one at either remove the centralized one I think we should have a distributor of flagging relations, because what is tribulus forgotten reduction? Okay with.

B

The process and I mean we. We want one document right, we don't we're it's not it's not Tony's document anymore. It's not anybody's document. It's LS are working group document. Now right everybody gets credit who works on it. Let's get past that right. Let's just get work done, and you know, and everyone should get credit for the work they do, and so that's not. That should not be an issue right, but we don't. Why would we have two documents saying that anyway, I thought we'd all agreed to it? It sounds like there's still some confusion.

B

Maybe we can talk about it. Offline and.

P

Also I think, therefore, that is Jupiter 1. There are some lists of a CBOC example. Are we for this Rubin one? We need a scheduler for exam or for Evernote, we'll use same schedule. Our buddy.

B

Have agreement on that and that should be discussed on the mailing list and if, for some reason, you're able to convince everyone that we should have a scheduler, it should go in the working group document we've already adopted. Is it's a generic thing unless it pertains if, for some reason, the algorithm you come up with that, you want to standardize no.

N

B

This scheduler in particular, then it might be appropriate to go in that specific draft right. These.

P

Are the DISA gradual is just we just maybe use adjust, but Evernote I agree and then use the same schedule as the same because it's scheduled.

B

P

B

If you think it's generally applicable to all all distributed solutions, and it should be going into our generic signaling document, all right I mean not into a separate one unless you're just proposing as a way to talk about it before we merge it in. But you know again: I thought you were doing and distributed algorithm hello.

G

And I'm from from Canada comma, you know, I have also parties Casa, really at least for the TV remote and the centralized mode and I know I, I, think I think the start point and the folks point of the counter working dropped either for the centralized signalized mode, but in general deployment I think the teachable monetary is more prefer and you know so.

G

There are overlap for these two documents and after discussing how separated separated and currently hermit charger provides some issue for, especially for the mundo he's super the most forged on what the f key beta I think they did unfair to put his solution.

N

G

The is easier into account mode, so I mean.

B

Do you say unfair yeah.

G

You know we're not talking fairness. This is standard.

B

Right I got that.

G

B

G

I know we are doing uh ideal, señor about the force that no standard, yeah I, think the way so the provide some different solution. The first thing is centralized honorees that he secures Rosa yeah.

B

We all agree that the distributed is, is one of the things we're.

G

Now, Larry- and you know all the easier- the solution are coming. First, the problem or after not a problem of the Pawnee stopped it.

B

Doesn't that doesn't matter, we separate we're separating the two things: it's not about the velocity right. It's we have a framework for signaling, which is not about the algorithms there's no algorithm specifying that document on purpose, because we want to divorce those two things we have signaling, which is easy. It's easy to figure that out it's hard to figure the algorithms out. That's where the work is. That's where the hook, if that's where the fame is, if it's very.

N

B

Up with a great algorithm right, but the signaling is boring work we need to get out of the way. So we can work on the hard problems. I.

G

Think the single union, but they can't be and and separated very clearly so you know I think we we should the survey that document.

B

So your opinion is, we should separate the signaling for distributed and centralized as.

G

Area there is no overlap for some. You know for FB people.

B

G

B

The way you're going against the rough consensus of working prepare the rough concerns.

G

Of the working.

N

B

Is that it's it should be combined into a single document. We adopted it on that, so we're probably not going to go back, but you know.

G

Go back, I, think of a ways to the go-go to achievement a solution. Now there are, you know, kind of the folks point that you, the kind of working group working document either for the personal item or the vo froggie in the final tab, Freudian flabby in the final project. You know this is I. Think.

B

I need a better understand. I, don't understand what your objection is. This is just how we do work in the idea. If we adopt a document, we all work on it. People nobody's.

N

B

To get credit for the work they do, we do discuss technical solutions, we discussed the problems, we discuss solutions and we pick the best. We try to pick the best technical solution for the problems that are there right, I mean if we need schizo. If we need to have tea bit, we need to have to keep it. If we need a scheduler, we need to schedule the TLB.

B

None of that nobody's saying no to any of this stuff, but I'm just saying it's in the wrong place here right, because we already have a document for signaling. Yes,.

P

I gave her more details, I think in your request. Option in your statement is that Tony's, a draft we're focused on the centralized, centralized I.

B

Said that was a mistake. I said I.

P

Made a mistake.

B

When I initially said that and and that wasn't what we agreed to at the end of the process, that's not where we landed I think.

P

B

Need to take that you know somewhere else right, because it's pretty clear from the email Tony had sent a mail at some point, saying I think we're looking at this wrong and and I said yes, you're right. We are looking at this wrong and everyone agreed to that. At least. Most people agree to it.

B

I'm, not gonna, say everyone right, but Tony, Tony reframed it as where this one is about signaling and the other ones are about algorithms, and that was a much more useful way to look at things and- and we have tons of agreement on that. So yes, if you know I, miss I, misspoke, originally and I'll. Take that doesn't we're allowed to make mistakes right?

B

P

Has a patent on good because it because the offering is based on that your statement and then ponies.

G

L

P

One you just asked me to remove the central centralizer one and then I've.

B

You know it doesn't matter we're the working, you cares and we follow.

P

The instructions and we move the second one and then just the fact that this one to to the new instructions.

B

Right so you're not happy I understand, but but what we need to do is we come out of this working so.

P

Happy isn't not award for describe of my feeling you see, so these are just my feeling, so they say that a big baby. We have a guru people working a very hoc by the way and now we're in an hour back to.

B

Credit and I said: there's no issue with credit. Anything any work. People do is not going to be hidden somewhere right if your work is adopted by the working group and we standardize it. Of course, your name's gonna be on it like that why? This is not something we need to discuss if you, if some of your work shows up in a document without your name on it, then I think you have something to complain about that hasn't happened yet. Has it yet.

P

There's no more cases, there's one guy in the middle. You said so after one program is about. It is even harder, though people put a new idea in that document. That's a normal case right, yeah.

B

What you're saying is that you think it's gonna be too hard to get any new work into the working group document that we adopted. Yes, actually, this is not ILS our stuff. This is ietf process stuff. So why don't we go offline? We can talk to the Hades to I.

C

B

C

Circular a circular discussion here too on this, so so I think we need to take that part of it offline. Are these technical comments? Everybody's got not processed? Yes, okay, les.

I

Ginsburg, so full disclosure I'm a co-author on the draft that was adopted, but the comment I would make in regards to the EFT bit without commenting whether it's a good idea or a bad idea, but operationally it overlaps with the definition of how we signal temporary flooding. And so, if we, if we're going to decide that this is a good idea, I think we have to take those two mechanisms and decide how to signal it and get both out of it.

I

If that's, what we think is the best solution, which is why it needs to be in the same document yeah.

P

I think these are different from those kind of requests a bit so request: three, the means that we send a request to the remote site and then we requires a decent thing to add: a temporary ID, a flattened topology. These are unjust, I computer, phalloidin, Papaji, Ricardo, dis link. This link is on the fly on the falada ontology, so just that this is a 44 cents.

E

Tony Lee Arista, so the way we make progress in the ITF is we make proposals. If you want to move forward with this, the right thing to do is to send mail to the mailing list proposing your idea. We then discuss it on the mailing list. If we agree, we then incorporated into the document. I have no objections to your idea. Let's talk about okay,.

E

P

Enough yeah regarding to discussion, I, think when, when the proposal those Libre document I say someone I, remember the Dropbox for positive as well as a year at the centralized one sinner single Authority should want it. Sudan can do it. This revision by themself, right, you're, right.

O

Maybe it'd be time to take this offline and talk to the chairs and the AAP. It's just a suggestion, as as a chair that.

C

This whole process anyway, so we'll discuss these two mechanisms as generalized mechanisms ah I as the scheduler, which I I agree that if you're going to do a scheduler, you don't need to disseminate the timers unless you're doing distributed, but for the FT bit we can discuss those two well discuss those two.

C

Okay, thank you. Hey we're, luckily we're a little bit early, but we're gonna meet again tomorrow and I would advise people to read the drafts, giving priority to the two we're talking again about the two rad I mean two rather radical extension, styie, sighs, I'd recommend everybody read and the other one. If you have time I'd recommend you read Sue's document on the use case.

C

That's gonna, be tomorrow as well. The other two I got a yang model. I can explain you don't really have to read. I can explain it in the ten minutes. I'm gonna talk about it yeah! Well, you don't have to read, there's only so many hours before the next meeting anyway and and the one on the one on on te.

C

We're going to have that presented. Maybe have some comments, but we're gonna move. It to the t's working group, the one on packet slicer, use the segment routing because it really didn't belong here, but we got the request. Late and I didn't really read it till the plane and I said well. This doesn't belong here, but it wasn't scheduled in T's. We had time we're gonna leave it on that. We cited leave it on the agenda.

C

It does have some minor te extensions in it, but that's the small part of the graph relative to the framework that is being proposed in that one. So maybe I got you curious enough to read that one as well by.

B

The way earlier, you know, since we've got a little heated there, if anybody, if everyone would go to the ether pad, that's what we're doing our minutes. Let's make sure we captured everyone's comments, because you know it's not always easy to understand each other, and you know if we put them down in the minutes. Maybe it'll help move that that process forward, so make sure that your your comments were there and captured correctly. We don't want to miss anybody's opinions.

N

The discussion in the end happens too fast, too quick, so I only captured, maybe 60%, of the whole discussion. So please go on the ISA pad and to you, whatever you said,.

B

Thank seeing Zen thanks. Everybody see you tomorrow tomorrow, tomorrow.

H

H

B

Anybody hasn't signed blue sheets grab it on the way out.

A

Because you know better yeah, you know what yourself exactly.

A

There are differences.

A

We find rats I, don't.

C