Internet Engineering Task Force 98, 27 Mar 2017

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF98-BFD-20170327-1710

Description

BFD meeting session at IETF98
2017/03/27 1710

A

A

B

Your name when speaking.

A

A

C

They anvita hell of a speedo good afternoon, everyone. This is BFE if you're looking for something else, go to a different group.

C

Ok, so this blue sheet should be circulating around know that that we need all that often, but we could be able to get a room when we need one. So please no solutions, so that's next slide. So this is the note, well you've, probably seen mobile times already. This does actually say that anything. You say in the mailing.

D

C

Microphone in a draft is a contribution towards the IETF. Maybe you could understand. That means. Please consult your lawyers excite, ladies.

C

So in terms of our agenda, we're going to just quickly talk about the status of some lingering things and then go into gooped Orioles, the sort of flavor of what we're doing for the next note hour or so is talking about gang and authentication, and the rest of the stuff is mostly.

E

C

Things slide so in terms of things that are in a zombie draft state. The mpls did is basically done at this point. Nobody sings be super interested in it. We still need to clear out some charter stuff without Alvaro and make sure that we actually get that off the Charter at some point, the BFD generic authentication and sha-1 is also in the zombie state, but courtesy of changes to the data tracker they've now put this in waiting for implementing and leave it. That way.

C

What sort of interesting it's their content occation may get resurrected as part of work moving day.

C

So BFD mol point is a piece of work that we do need to close off. You know the face multi-point document does have implementation at alcatel also has interested several other vendors, so we do want to actually push this one through standards. The active tail document is not, basically, you know, still a good idea, but it's unlikely to see you know deployment anytime soon, ish our general ideas that we want to publish these things, ideally within the next IETF cycle.

C

So what we're going to be doing is looking for a document shepherd to pick these things up. When we last talked about this at ITF 96 know, Greg said he might be interested, so we will their talk to Greg and see if he wants to actually carry this through as a shepherd or no, but for somebody else that they have time and what will actually be doing is just running this through no last calls will be working with outfit I'll make sure that the procedure that's documented.

C

There no covers what they're actually doing, and this is I etfs chance to say this is a good or bad idea.

C

So the draft that Greg and Jeff come Sura have been working on for basically efb over mopey chassis, which is basically the same thing as VF p.m. like just the multi chassis environment had them presented IETF 96. We had good sense of the room at that time that the work is in scope for the working groups. You know very similar to the VFD em like stuff.

C

There has been no updates. It's reasonable material at this point we're be doing, is putting this to adoption on the mailing list and we'll try to get consensus.

D

C

That great, please, a comment be like.

B

um Mirsky city, so we had very interesting comment and good comment from John messenger at the discussion in Berlin referencing, a new extension to 80 to 1 x, black specification with a distributed resilient network interface.

D

B

And I, so I looked at specification. Yes, I agree that that makes MC.

D

B

D

B

A special case and Jones suggested consider bringing this work too I Triple E. So my thing is that I don't think that I truly will be interested in using layer 3 protocol to monitor layer to object, so the interest that they probably will work on, extending 1731, for example, or CFM. But what I would like of others?

B

Member of the community to consider is that if there is an interest to generalize for one using dvd-r and I or MC lag is something that we would like to address first and see if there will be implementations of here and I, because it's much more flexible and more powerful. But as a result.

F

B

Much more complex.

C

So I think there's enough context there that the mailing list is probably the best place to have this discussion. So if you could basically frame this in a set of questions for the working group to discuss on the mailing list that that offers advanced this, this is not the first time we've run into that sort of headache. Wit, I triple e before, when we're doing the fdm lag in the first place. It's it's obviously a weird mix between layer, 3 and layer 2, and this is just sort of the opposite end of the equation.

C

Next slide so we're going to go into our presentations, we've chosen to start with eft yang, which I will actually be doing, that big.

C

And just in case somebody wants to help with minutes. You know minutes are usually pretty easy here we are using the etherpad and I welcome people helping a to keep the notes.

G

Can you hear me the good yes.

G

Okay, so I'm going to give an update on the VFD yang data model next slightly, so the changes in drop 05 since drop 03. We basically not two sets of changes that make the first ones were. We fixed the the were compiled issues in indy 03 version, which were found when we started using new young compilers, and also the biggest change really was, as all many of the other routing models were doing.

G

We were planting network instance and now we're using the schema, not approach where we define a model and that model can be mounted in the network instance or at the logical device level.

G

Also, now the routing draft became RFC 8080 22 yep d is now mounting the base identity, which will be fine as a control, plane, protocol map and I've added the section on interactions with other en bottoms.

G

Any questions on this slide.

G

What's still not there yet d / DC cv4 to the wires, so one thing I've been waiting for is I. Think the l2vpn model was going to fair amount of churn. It seems to be more stable. Now, there's a new version which was published last week, I think, and so one thing we have to decide: I, don't if it's something we discuss on the.

F

G

Authors or here.

F

G

Whether this model should cover the FDB CV or whether we cover that model in a different gang model and since day one we haven't had any yet I bfg over mpls-tp and we've decided that we will not be covering that in this draft.

G

Our pcs, up to now we've been said, we've said it's not needed. Greg will talk about echo later, where the question of our pcs came up again next slide. Please actually.

C

Pause on the slide, so in terms of urgency, whether you should wait on the VC cv, I think the big question is we're getting pushed to publish yang metals and I, see our ad hiding in the back of the room. There I offer that you so then why no is actually been pushing us to get these things up. Lished. You have any personal sense of note. Should we just get this thing out and put in the augmentation and later because that is an option with yang or you know, should we just close this off.

H

D

Of Rosanna rubbing a big.

H

Yeah, who was me I, would you know I have no idea.

D

H

Say this have no idea what it means waiting well to leave. You have to firm up how long that's going to take like, so we might be sitting here for a long time. So it hurts me. I was just do.

D

H

Additionally, ok.

C

You know so our job is written groups. Make sure that the structure of the a module is good enough so that we can do the augmentation correct.

G

I mean right now, the way it is. Is you go to base model and then all the VFD for each organ type, basically augments from there. So we could have a separate module where it yippee for a store, I mean I could even try there's an experimental thing. You know how it would work, the current, healthy and modeled. You get confidence that could work up in the future.

C

G

So things which okay open issues, so there was the discussion on the alias about whether the echo transmitted.

D

G

Was defined properly as being a kinetic parameter, whether that should be in RPC, so great, we'll talk about that it wrong to me that comes down to the question is: is echo typically use as on-demand or something which is continuous?

G

So if anybody has any comments on that now or later, when Greg will present, please then last not least it's it's I mean it's not complicated, but basically spending the time to comply with sixty eighty seven days, which we haven't done yet and yeah next one please.

G

We also got a bunch of comments from Jeff last week, which will I think were on board, for most of them will talk about. Those will have your address. Those will have to address the open issues on the previous slide and I. Think after that, we go to yang dr. with you.

B

A

Only takes a month at.

B

Least you get the preview I'm. Sorry, it takes at least a month to get someone from young doctor caribian.

G

Questions concerns.

C

B

Nice and straight.

A

C

So Greg will be next to talk about the echo implications.

A

C

The comment that your eyes are much redder than mine. Look at the tiny pond safe.

A

B

Yeah, okay, um so.

B

I just put only two spots: first of all, it is just to recapture what RFC 5880.

B

Says about VFD echo, so there are two.

A

B

A BFD echo format, the payload of the packet, is not determined.

B

Now what being sent as the echo is open to implementation, it was a proprietary.

B

Second thing is that it's a symmetric so in a symmetric in a way that.

B

Give D here note the note advertises only based on a standard are their desired minimum receive.

D

B

So basically it says states don't send me anything. Leave the echo more frequently than this when comparing to a synchronous mode with it, advertises minimum receive and transmit.

B

Okay and as a result, it's absolutely normal behavior to see that only one of VFD peers is using echo, while the other one is not because, for example, the other side might just say zero, which means which.

D

Should be interpreted as don't send.

B

Me any echo ah messages so in another interesting.

B

Passage or mechanism that described in 5880- and I think that's where how difference in interpretation comes from, is that it suggests that sending VFD echo may be accounted with presence of a synchronous, BFD control messages and if echo message is being sent so their rate of VFD control messages can be reduced.

B

Accordingly and in current give the yang model their model is such that there are two things so the first thing the model includes the transmit echo interval as part of the configuration which is it persistent configuration and, second of all. So from my point of view, echo is not proactive mechanism as a synchronous being demoed, but on demand, and in my.

D

B

Slide, that's what I want to stress is a difference again in my interpretation, what are proactive and what on demand OEM is so the practices you always have persistent configuration, whereas the on-demand doesn't have persistent configuration.

B

So we had this discussion, we start a discussion on a working group.

D

B

And then we were soon realize that, yes, we have a different interpretation of the.

D

B

Some of it is to do with this recommendation in 5880, which says that if you using echo, give deep then it might reduce me to send control messages, as the messages can be accounted.

B

I'm not sure that on demand will make it absolutely impossible to do this. Correction of the rate. I, though, wonder, is that if we reduce the number of messages, that will mean that we reduce the interval and will change the state machine so interleaving with the ekka messages, determination of Thaler.

D

B

Somewhat ambiguous this, it's not deterministic, of which one of the state machine and.

D

B

Has to really constitute there Taylor echo mechanism or a synchronous or composition, invoke my interpretation or 5880. It's unclear so.

C

I think this is a place to interject. You know what we see the real world so with regard to, what do you do about the DFT state machine, especially when it sort of down negotiates it is part of running the echo function. What we tend to see in the field is that echo is there to say that I am taking full control over whether I consider my.

D

C

Reachable or not simply by the fact that I'm seeing my traffic mutiny, my payload is my choice. Hi verification is my choice, so this is taking it a bit out of the snake machine because it is now fully under control of the initiator and I think the FD is requesting is that the session not exceed to give them a packet for second rate, so it is to some extent the choice of the implementation as to what it wants. Did you get? What I think this does and towards the yang module, which is the original points?

C

Conversation configuration hasn't changed? No, we have what the user had put in as it's the tent for know the async session, and also for the echo session operationally. You know we're always going to show what the active state is know whether you know we've negotiated our timers down is Carter running the protocol or, if we're still running at the great that was virtually configured.

C

What might be absent from the model that maybe you could offer some suggestions on is when we've done this no down negotiation? We can see that in terms of the settings of the async session, whether or not the echo function has any sort of representation, operational state I, don't think that's there right now. I can't tell that echo is actually in progress. I can't tell what it happens to think about this, and the problem is.

C

This is left explicitly out of the spec as a I'm not going to talk about this, which makes a little hard to put it into a standardized yang module. I think what we might be able to expose is echo function is active.

E

C

It is working or not if a implementation wants to augment the dfb module to say something about what it's injecting that's great, that I think that's probably in the space of a vendor, augmentation technology um right.

B

Again, stepping back original discussion started that the transmit interval, whether it's part of persistent configuration before it's a part of our PC.

B

Even if we extend it further, is that initiating at session ah is it. The part of configuration has been able disabled or it's important part, so I think.

C

In terms of the management editing, so the egg module that we're talking about it's an inherent property of the end user, so I would not expect to be up to implementation to prod the yang mult. Initiate a echo activity is its way of interacting with BF d. Now this would be something the internal software into the place where you'd want to expose this in the yang module is, if you expect the end, users use the management claim to actually initiate something.

C

So in the case of something like spfd, which is really on demand that might make sense- and you know, spfd functions- are not really covered strongly inside of the gang module. At this point we know those would probably could be something we want to augment at a later point.

C

So I think my observation would be this sort of on-demand behavior triggered by the management plane. It's probably otoscope for what we're trying to do for this first round of things, but, as we talked about spfd may be excited the muses event.

B

Actually, as you bring up SBB.

D

B

There is a certain dependency as BFD to the IGP from.

C

Its dependent on another state as sagittis one way to do one way of really.

B

Advertising discriminator.

B

C

B

C

By provisioning.

B

Ok but again, I just wanted to bring up this question of echo.

B

D

To the discussion, because.

B

You see whether we think that I could transfer part of persistent configuration or of something else and.

C

I fortunately, I think it's out of scope, but it is definitely a good place for a vendor application.

B

Then so you will consider is that to being not in the base model? Okay, that I. Would you, okay.

C

Thanks for your bringing up the topic.

C

Ok, so I think holding on to our next slide, so we're entering the portion of our session where we're talking about if the authentication and things they'll be being used for our first presentation from that will be subtle.

C

Just a microphone everyone.

I

So um today I'll be talking about and you can you.

D

Will do if you take it out, take a bell or lower in the Lord.

C

I

Today, I'll be talking about an enhancement to RFC 5880, so the the reasons we have this enhancement is 5818 states that the authentication is done on the entire packet.

I

If we have a key 10 B 5 of food sha-1 other but and the other thing that it states is that the sequence number is exposed in every DFT packet. So there is an enhancement we're making to the security of the faculty or that states.

I

We actually don't have to authenticate the whole package, because it's expensive when packets comment line great it's expensive to decode the authentication on the entire packet, and we can authenticate parts of the packet and the part of the package that we want. Your tentative is the sequence number, so we want to protect that and that's what this graph talked about and also the authentication is not on the whole package. It is just on the sequence number and how we can hide the sequence number from all intruders. So that's the reason for this enhancement so.

I

So the problem is that sequence numbers increase monotonically, so it is, it becomes very predictable. What the next sequence number is going to be. So when that happens, it's easy for the man in the middle to bring down the PFD session or take control of the deity session. So, in order to avoid this, we've come up with a proposal.

I

Ok, so the high-level algorithm is that you take your sequence number, which is increasing and you push it through a hash algorithm, which is a symmetric, 32-bit hash algorithm.

I

When you hash the sequence number in the hash algorithm with a shared key, the sequence number is now hidden from anyone who tries to intercept the package. So instead of placing the sequence number in the sequence, number field or the packet, you place the hashed value in the sequence number of accounts. So that's the high-level solution.

I

Ok, so basically you provision a hash, algorithm and a shaky securely on the sender and the receiver, and this has to be a symmetric hash. Well, the reason is that the receiver has to perform the reverse hash on what the sender did.

I

So the sender encodes, the sequence number using the shared key and the hash and the receiver decodes the sequence number using the reverse hash and the shake the expected sequence number will match the decoded value and the receiver now knows what they expected. Sequence number would be if the sequence number is match up using the reverse hash, then you know that the fact it is good. Otherwise, you know that the packet is a bad product.

I

So this is just an example this. This is just an example on all the sequence numbers that would have individuals. So on help we have what RFC 1558 uses, so it uses increasing sequence numbers and when you have a hash with a shake either just random numbers I chose is to show that the the array, the low, is basically the sequence number when completed in hash, with a shape.

I

So in 1580 you have the hash on the whole packet which, when you have to decode the hash, it's expensive, because it's on the whole packet. But here this is just on a 32-bit value that is hidden from all attacks. Now it it provides a level of security, because intruders will not be able to detect the sequence number and hence won't be able to bring down the VNC session.

I

I

There there two things been achieved here: you're not hashing the whole packet, your action, only the sequence, number and you're also protecting the sequence number from being extends from the mall arm introduced.

C

So we're going to get into a broader discussion is after the next presentation about now the optimizing vfp draft will be doing something slightly out or the agenda and what should hopefully become a parent. You know from the update is this mechanism is intended to address the one of the problems that we had when we were sending you know unauthenticated the FD packets, in the clear we want to run authentication less. How do you run event occasionally without actually making ourselves vulnerable during that time? Demand in the Middle's?

C

So please feel free to ask questions now or no ask you know, combine questions after the next presentation.

G

So up here, if I have a comment, this is when you say without authentication here this is assuming the Nullification tlv of the optimizing graph.

I

G

So you guys really intend to have this as independent side by side.

I

The other God can also make use of this. Like this point,.

C

And what sort of worth pointing out is that this mechanism can be used outside of the FD know? Basically, one of the genetic problems IETF has is, if you want to make sure that you have some piece of high volume data PFD being an excellent example of that, where you can't afford to do an actual hardcore crew, neck action like no sha wan xiao, xu et cetera, that this mechanism for data that has a short lifespan may actually be a good way to provide no eating great security.

C

Well, thank you. Let's proceed to the optimizing presentation.

E

B

C

Take some sort of it these two things.

B

Alright, so this is an update to the draft that we have been discussing in VFD for some time, as Jeff mentioned, one of the action items that we had taken from the last presentation was the question of how to deal with our nothing to gated packets that we had before that.

B

If you don't need to essentially authenticate every packet- and we can bet the remaining packets going here so I'll come to that and how solos draw kind of fits into this.

B

So just the other update is, of course the consideration are behind our consideration that are not lost, I believe in right now, so we are asking for an addition or not allowed in that makes likely so in the proposal that we had made, which suggested that only a beefy packet that is actually going to make a state change should be Authenticator or needs to be authenticated that the remaining packets that do not indicate any state change can go in the clear, but that brought up the issue of what happens if someone actually takes over a session.

B

At that point,.

D

B

Seeing the Packers going there and tries to bring the session down there, this is so. The action was one of the recommendation poster for us to say every so often we'll go and authenticate one of those packets just to make sure that possession hasn't.

D

Been taken over home.

B

That's only as good as we do it in enough frequently enough that we somebody can't get in the middle next slide. Please.

B

So this is where, on the suggestion of taking what is already our tunnel presented in terms of birth, using be meticulous sequence, number and saying that if we were to hide or a bunch the sequence number, then we would be actually be able to prevent the man in the middle attack. In the cases where the packet is going into clear. On next slide.

B

So pretty much as I said, the draft has been stable, except to deal with this particular action item that we had about the beam but sequence numbers, and we believe at this point of those that the document is ready for lost all questions.

B

Gregory ett, so my question is that in a draft, so you indicate that one of the possible modes when their sessions up is to use authentication with some periodic thinner trigger.

B

Sorry say that again to use I think the authentication as a timer trigger so basically ever so often to send the packet with authentication. That was one of the option, and that is because authenticate in each and every packet is computationally.

D

B

Though, when I think about hardware-based via the implementation, so I think that there, then the idea would.

G

B

Verification of authentication is uploaded from their polling.

C

B

Ok and then raises the question is when we say that the received packet with an authentication being validate when we complete authentication verification or when we just verify some.

D

B

The pack it is, then the packet is completely authentic, ated, okay, but that affects their state machine, because I can.

D

Envision that the rate of sending packets.

B

It's quite aggressive yeah, but when you're doing a straight change, you're not under out McDonald.

D

B

You indicated that it's possible to use authentication when the state is up right. Okay,.

G

Examiner, it's only occasionally every.

B

One sec right, but occasionally every so often so you sending the packet. And then let's assume that after this packet being shipped for syndication verification, we lose two packets in a row.

B

Okay, so which will cause a stick drop two down, because if a syndication takes more than time then receiving.

D

To Beckett.

B

A

B

Say: you're not able to authenticate in time because packet right? Yes, we but you received two packets off. No, no I don't receive I drop. I lost if.

C

I could I think what Greg is suggesting that, in a hardware based implementation, if you're trying to keep the authentication of the hardcore authentication in line on the line card, the action of doing that, they burn enough resources that it causes a cough drops. No.

B

But what no it's not.

A

No blood smear I.

B

Imagine that it's like a authentication as a bump in the wire, so a tent occation, gratification being shipped to control, plane and I have a high rate of packets, so, let's say running at 3.3 millisecond and let's assume the control plane, it's so busy. It cannot get to process this packets in the next seven milliseconds, but so happens that the next to be a package that's supposed to be processed by hardware.

B

That was so what I have I have one packet: that's still waiting, processing and two packets being lost so I'm out of my death interval, true yeah. So in that particular scenario, you're left with no option but to bring the session dog yes, okay, so you think that it doesn't have to somehow change their validation scheme. So that leaves this packet, that being accepted and sent for authentication validation, gets counted as a valid packet.

B

Well, one possible implementation and I, don't know is that before you bring the session down, if you already have a packet that you know is waiting authentication completion. Can you but II made on that yeah? But if single authenticated packet fails to be validated, does that bring.

D

B

Down because again it's not in a document. Okay in did you have a comment to the mine.

E

Hesitate because it's been awhile since I've read this, but so I'm working from memory right rather than the document, but it's a authentication is essentially a separate process. You just keep receiving the packets and if they look right, you assume the session is still up at some point you get around to validating whether or not the FN occation is correct. You go. Oh damn, there's a problem that happened a little while ago. Let's take it down or let's set off an alarm, that's the only trigger that is associated with the detection of an authentication problem.

E

B

E

And you just keep going I, don't understand Greg, but you're and maybe I've just misunderstood. You.

A

E

Not blocking on anything if you have to lose two and you're counting for three, then you keep going so you don't get three yeah.

B

I'm, assuming that, if you're using your indication that you aren't dependent, you encrypt the.

D

B

Pack, the whole be of demons, so only putting.

E

A checksum on the package not actually encrypting it unless you changed something. No, so it's.

B

Gian I think what Greg is referring to a previous option he's not referring to the suggested changes that we're making he you know previous option. We had recommended that every so often every one second, as a suggestion, we would encrypt a pack, and in that case, what Garriga saying is that the timer will expire. Therefore, the system will have no option but to bring the session of and I accept. That argument.

F

So, let's convert I'm just curious. This discussion assumes that it's a practical problem that authentication cannot be completed within the session whole time. That is, that a realistic problem, every.

C

Does anybody know so it's not specifically that problem. It's doing that same thing. Every three point: three milliseconds you.

F

Know so, but that's.

C

An elaboration if it doesn't arrive rio salado and that's why.

F

C

F

To say, let's not do that on every packet, but every nth packet and now you're, saying gee what happens if I lose the other end. Packets and.

B

I'm, asking instead of practical.

F

B

Won't say that usually you.

F

Might have thousands of.

B

Feedback sessions so yeah.

H

B

To the argument, a guy, ok, I'll I should have last time to what he's saying it's not just that it's an authentication is not only for that. Packet is taking more than people in three milliseconds. It's actually taking nine point: nine milliseconds for the authentication to succeed before for you to be able to say: oh I, Kiva's I lost three packets. Now, if you're not able to authentic authentic 8 the packet in nine point, nine milliseconds and yes you're totally out of luck, you probably shouldn't even be doing authentication to begin with.

B

No but again uni.

D

Monster hardware right prevalence, yeah.

B

The thing is that we can talk about multiple concurrent give these sessions, which is usually the case okay, but.

D

The same argument.

B

Meaning, if, if you truly, if your hardware is not capable of authenticating in every nth packet, then you probably should but.

D

Again, the premise.

B

Of this word is that, yes, we realize that authentication is expensive and we want to somehow do it.

B

Theoretically, not every peg, because.

D

B

That's not a problem if performance is not a problem, then why we do it theoretically, why we not authenticate each and every tech? Okay right, I know for a fact that authenticating every packet at 3.3 million seconds is a problem. What we don't know is that, if indicated, every nth packet is a problem, I agree. We won't be proposing this.

B

If we could not do any authentication at all at wire speed I can I can assure you is that if we have a problem, authenticating every packet and we start authenticating every one packet in a thousand then with a thousand sessions, it still will be a problem.

F

So this to me is it's a scale problem forget about authentication for a particular hardware. I can support and sessions that might be 10 that might be hundred there.

D

F

Be a thousand so now we're increasing the cost of supporting a session that clearly affects your scale, so maybe the hardware they could support a thousand unauthenticated sessions could only support one hundred authenticated section together. Yeah.

B

F

Free, it's not obviously.

B

Three, but the thing is that we are changing the flow of the packet. So in a system, because if we have indicate each and every packet, then the processing of the packets and validation is friendship. So if we are shipping.

D

Authentication.

B

Somewhere else are floating, then we are changing that suppression, okay, because so they're, not a man and jabber from.

C

Specifically on this point, let him get his words in jail, so in Hardware implementations the sequence number option will be better fit compared to a scenario where indication is not in mine.

C

In any case, authentication of the offloaded frame is not related to the subsequent frames, so more than one person's making the point that, even if you're changing the path through which the authentication stuff flows, you know doing the fast stuff in line doing the expensive stuff, potentially on a different engine, the fundamental property that you care about is: can you actually do this work in a timely fashion for the scale that you're looking at and, as you start know, this is a multi-dimensional problem as know the FD always is.

C

If you increase the numbers on one thing, you change know what you scale on the other ones. So if you could support authenticating one out of n, that's great but as Greg points out, if you make end big enough, you'll eventually run into enough of indications happening potentially at the same time, because you know some level of headache, one thing that the FD tries to give us to help with the situation.

C

A little bit is we're expected to buy jittered I think one place that we might be a little bit better descriptive in our question about the periodic authentication is some way to maybe make sure that that jitter applies to that type of behavior. So we don't end up self synchronizing sounds.

B

Good, so that's something somewhere! You can lab for the gun.

B

Okay, all right so we'll make those changes and resubmit. The draft or consideration.

G

Allowable the question which only been asked before has there been any experimentation in terms of what kind of we can scale x times better with this, as opposed to what we're doing it's.

B

um Not specifically with authentic this form of authentication, the difference between no authentication and full authentication was I believe one in five, so the numbers dropped one. Fifth, if you for the.

F

C

For authentication.

C

So, in terms of the actions that come out of this I think we're probably slightly premature on last call: you did the procedures I think are well understood. You know it's just a matter of how do we hold in the procedures from sonals draft to cover the situation's we knew where problems some of that includes. You know how we actually do. The initial sequence number discovery in.

D

Order to be able to do the hash.

C

Of the sequence numbers for the cases worth buying that mechanism, so I, don't think we're ready for last call, but no certainly after integration- they probably are. What this does mean is that now we would, as part of this work, also need to take up. Sonals draft is, you know, basically dependent draft and therefore make it a brick. Your baptism is that what you're looking for yes.

B

C

Assume so, but you know you always have to ask, so what we'll be doing is part of you know. The post-meeting stuff is putting out an adoption. Call for this. Make sure that the briton group agrees, and hopefully we probably said it for about two weeks after I ETF is complete and the two of you can sort of work together on making sure that no, your solos draft is actually covering procedures, know that are sort of generic and.

D

C

Draft is covering how to actually integrate.

D

C

Procedures this all this visit problem right.

G

Can be optimizing, dropped, go to last call without the sequence number of Fisk a shin you're going to last. All that.

D

If you're actually going to use guys.

B

So it will probably get held up in ISC or whatever ask all the fading force holds back to beach.

C

A similar state yeah so in terms.

B

Of publication, it.

C

Does mean that both graphs must advance together because they have a normative and.

D

Then see on each other.

C

D

More importantly, we.

C

Can't last call optimizing until we actually have the procedure making use of this mechanism a nail down back.

F

B

C

H

C

We're on our last presentation, this is a update on the DFT performance mechanism.

B

All right, so this is an individual draft, and the questions raised in the last meeting were related to several questions, actually how the delay measurement was going to take place.

B

Where was the values going to be stored to see both sender how the two are going to get correlated so that and the other was what impact, if any it would have on the optimizer draft that we just discussed next slide, please so with all those the considerations I'm, considering that it really wasn't trying to solve a whole lot of issue that people already didn't know, we decided to drop the delay measurement calculation, but keep these you can sum up the validity count and see if there were any DFT packets getting dropped in a VIP session and using that as a mechanism to figure out whether the deity session was stable.

B

It's still very much there and you see quality and ability to use that to figure out our predict whether they're going to be a network event that might ultimately bring the VAP session next slightly.

B

We believe, having dropped, that and made a very simple drop, all about counting sequence numbers and making sure whether that is a is a good enough indication of the state of the BFD and of the network that we believe that it has some value to be considered as a vodka file.

C

Any questions or comments on the APFT performance, this does clear out one of the security concerns that was their feature of merely using the same mechanism.

G

Also honkers who's read the draw.

B

C

Ok, so both will take the adoption request of the mailing list. That said, we have four minutes left in the session unless there's a any ad hoc business we are concluded. Thank.

H

C

You have not signed the blue sheets, please do so.