Internet Engineering Task Force 104, 28 Mar 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF104-BABEL-20190328-0900

Description

BABEL meeting session at IETF104
2019/03/28 0900

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

A

Oh good morning, people there, maybe it's good, there's a little bit later in the week, but it's a little sparse and there's a couple of speakers not here. So maybe we'll wait. Another a couple minutes there.

B

C

Uploaded his wattage at 2:54 am.

D

E

Let me see must have been on some level.

A

Okay, okay, so we'll go ahead and get started here. This is the table or Babel working group, depending on what you feel like I'm, not Elise lake, with whoa a co-chair either co-chair of Russ white he's not here. He we originally an English scheduled yesterday when they, so he was planning to be here, but he made arrangements to leave either this morning or last night, I'm, not sure. So when we got rescheduled for today, he was not here so.

A

C

A

Note well probably you've seen this before or would you read it we're operating under the IETF IPR rules? If you make any contributions, including saying anything during a meeting, you need to declare any IPR, you know about that. Hasn't already been declared and there's a bunch of other stuff. Here too, you should look at so. Why wasn't this.

A

Surely there's a mode of this where it will age I thought that mode we should be correct. Yeah, oh.

F

A

A

A

Doctor people should review documents if they want their talk in to be reviewed and that's what improves the quality of documents is the reviews, and hopefully, the resolution, of the comments made during the reviews.

A

So it still isn't in a mode where it automatically goes from one screen to the next.

F

F

A

Not sure what do you mean, if you mean the little, the four up right down left and right arrows? That's the only thing I've used, I haven't scrolled at all. During this.

F

A

Hitting the down arrow right, left and right, oh right, somehow that doesn't seem logical to me, but anyway moving right along agenda. We have an agenda, so we should bash on it. If anybody wants to make any change, the plan is talked a bit about our status of milestones and Jerez, which is I, think there's good news there and then presentations on changes to available bubble, h, mac, r, TT, based routing information model and the.

G

Yang model and.

A

We'll wrap it all up.

A

Anybody wish to make any changes so.

H

It's just one note: the model is at the yang model. This is now I. Have a group document published.

A

Yes, it's Charlie's, just me, it is I, have tricked it everywhere else, I'm, pretty sure he died, not too surprisingly, I do the slides for each meeting by editing the slides for the previous meeting and I failed to change it here. It's draft IETF novel yang model. It is a working group draft.

A

Okay, no requests for changes so we're now that's right. There document status, so we actually have a nifty kind of like sort of cohesive set of four documents with publication requested the applicability, the two security crafts DTLS and HVAC and RFC 6120 six bits. So it seems hopefully that package will advance.

A

We do have three working groups, including wrapped IETF babble yang model, which it's correct here. The and the source specific end information model drafts which are in working group last call are there related drafts. There's the home net babble profile, which is in the RFC editor's q in miss ref state means it's waiting on normative references and the to normative references. It's waiting on our RFC 6120, six bits and the source specific draft, and then there's the doughlas fable, RTT extension graft, and this slide also shows the previous set of three experimental grafts.

A

So we just moved the milestone of submission of RFC 6120, six bits to the IES g RT to our ad, to be more specific from the to be done to the current ones. Were you know kind of behind relative to the actual dates on the current milestones? But that's we are making progress, I believe on all fronts here.

A

The management draft, the last one is is intended to me refer to the yang draft. In my opinion, so that's kind of the status of things I think I'll wait till after the presentations or there were a couple of working group. Actions concerning adoption and last call that are I said, would go through this meeting without I. Think I'll do things related to those at the end of the meetings or so any questions or comments on that I guess not. Then we will proceed with the agenda and with Julia's presentations.

A

A

Oh boy, how do I get to the next thing here.

A

That's not what I want a break.

B

A

I can't align all I say if it's taking a while. Okay.

A

A

Okay uh and you would you like a control device, I can do it for you.

I

So hello, I'm, Julia scrub, Oh check and this thing over there is my name and if you're ever wondering why I have so many strange consonants. That's because it's written in the Polish spelling system, which dates from the Middle Ages. Now the checks over here used to have a very similar writing system. But then, in the early 17th century there was a great reformer Covey on who's who redesigned the writing system to make it sensible.

I

So if you ever look at my name, please use it as a cautionary tale about what happens when you come to ITF with an already deployed protocol and are too concerned that ever backwards-compatibility next, please, okay, so last summer, together with things online and the Veronica kodiak, we set about to design a authentication method in for Babel. That would be as simple and as comprehensible as possible. So I know nothing about cryptography and the design criterion was something that I could understand.

I

Okay, that means no DTLS, no complicated libraries, whose security properties, our difficult understanding requires some knowledge, and so it ended up by being a and it ended up being based on the work on a number of people.

I

So it was based on some work that had been done by Denis of Shenko in RFC, seven, two nine eight and we had a lot of in good and in particular, so I've tried to be exhaustive in the acknowledgements, but so here I will only mention Marcus Stenberg, who gave us some very important ideas, because some properties- and we ended up. You know we did the opposite of what happens.

I

Usually, usually you have ambitious plans and you end up realizing it's difficult, and so you scale them down, and in this case, actually we were expecting to do and that turned out pretty well. We got a protocol that protects both unicast and multicast. So remember that in Babel you have both unicast and multicast packets. Depending on the pendulum well various details of the protocol. It's not vulnerable to replay it's reasonably easy to implement it been actually reimplemented by Toki and the properties that make it easy to implement are that we don't require the global clock.

I

There is no global counter in the network and there is no persistent storage. So barbara was telling me at the time. Well, why are you trying to avoid persistent storage? There's? No such thing as a Rooter with no persistent storage? Well, the problem is that persistent storage is very difficult to do right. Okay, depending on the hardware you're on you might have a hard disk. You might have an SSD, you might have some proprietary NVRAM and trying to access it.

I

Transactionally is going to be very difficult, so I've preferred to sweep the problem out under the rug by not assuming any persistent storage. It says algorithm agility. There are a few parameters you can change depending on what your needs are next, please, and what we did was that we did everything on the mailing list, because I didn't see a competent, so the two ladies, our cryptography student, they understand cryptography, they don't under. They didn't necessarily understand route routing protocols at the time as to myself.

I

I know apps and you absolutely nothing about cryptography, and so we did everything in the open on the mailing list, except for two things that were done more recently and that I'm going to tell me about which were mentioned on the mailing list. But didn't really have a lot of discussion. I hope they will be non-controversial.

I

We changed the mandatory to implement nack algorithms. So now what it says is that you must implement sha-256 and you should implement lake 2s and that there is an additional requirement. You must discard your neighbour cryptographic state after a bounded amount of time, so the original RFC seven to nine by that done by then had to mandatory to implement algorithms. They were Shaolin and ripe in the 160.

I

Now I think that's fine, but I was told that Shaolin is not recommended in new protocols and one person who does understand cryptography told me that try, candy 160 is somewhat niche.

I

So in the latest version of the draft we say that you must implement sha-256, you should implement like 2s, and the intent is that those are most must accept that you've written should in the draft in case you have some very good reason not to implement like 2's, if you have no good reason to implement like 2's, please implement both and we implement both in both babble, D and Bert. Next, please look I'll, tell you the whole truth.

I

The hash function just doesn't matter so, first of all, we're only using the hash function for authentication. So if there is a first preimage attack, that's something difficult, I'm, not sure what it is. That I'm told it's something difficult, but then we are threatened, but we are not threatened by collision attacks. If somebody manages to do a collision attack, then we are not threatened by that, so any hash function. You may conceive for its strong enough.

I

According to my computations and I'm, not a cryptographer, but according to my back of the envelope computations md5 would be strong enough. Md 4 is too weak. Ok, so anything you use reasonably. If you have a reasonable, reaching interval will be strong enough and you're only hashing the control packets. So unless you run in Babel on an abacus, then any hash function will be fast enough. So really it doesn't matter. Sha 256 is clearly overkill for what we are doing, but even that will be fast enough. So it's fine. Next, please.

I

However, some people are concerned about slow software. Routers, like the things you get in your home, with no hardware assists for sure, 200 56 and token they suggested Blake to s. I've done my homework. I've tried to find out what is uh what is the world like to us? Actually I asked Paulo Xavier to come I'm grateful to do my homework for me and what Paul have been telling me is that it's blazingly fast and software.

I

It has 128 bit lengths, it integrates keying, so you don't need to hash over the result of hashing, because the King is integrating the protocol. You don't need the H Mack construction and the issue is it, which is the reason why it was rejected as shastri is that it's based on very similar principles as char 256, and so if sha 256 is broke and most probably like 2's will be broken too, which should not be a problem for us, because even if it's broken it will still be strong enough for our needs. Next, please, ok!

I

So that's the first thing: the change in the mandatory to implement hash algorithm. The other change is that we've added some protection against delayed packets, so babel h, mac is invulnerable to replay. If a packet has been used once you will not manage to use the same packet again, it's also involved to reordering, but it is not what it is vulnerable to is packets being delayed. So if a packet is in the right order, it can be delayed by arbitrary amounts of time.

I

Now, if the attacker is at a network switch, it might be able to block packets and then send them later. We don't know any attack that could be against Babel. That could be using delayed packets, but the notion that there are packets that have been sent identified and they're replayed and they are intercepted and then sent say 2 hours later, is something that makes us nervous. So we've added next, please so one property of the protocol is that a node may at any time discard its perkier cryptographic. State.

I

Ok, so you can say: ok forget anything about the exchange I've made with a given fear, and then there is a mechanoid called the challenge mechanism that will create a new cryptographic state at the cost of one RTT of lost packets, and the node can do that at any time. And what we added is that now a node must we discard its cryptographic state after a bound at time with no correctly authenticated packet? Okay, so we don't give any figures for the bound.

I

We say you must ensure that there is a bound and the time on which you keep cryptographic state for somebody who's, not speaking to you, okay, and we are not specifying the mechanism, but we do give implementation advice next, please so we've made it to non-controversial changes to the protocol and like this random. In this talk, thank you for attention.

G

Michael Abram just a clarification, so you're doing this as an offset in time from now, and they don't have to have synchronized clocks at all. There is no requirement for the different devices to agree on what I.

I

G

I

We have, we have surprisingly weak requirements. I'm still surprised. We managed to do that and if you're wondering where the catch is there's overhead in the packet, there is basically that costs us. Eight bytes per packet have overhead.

G

Yeah, just that's a typical thing that cryptography people don't might realize that a lot of these things don't have an real-time clock that is battery backed up and they might come up with any time whatsoever and I see this all the time. I.

A

Mention there this ability to discard the cryptographic state scheme is really good because that might happen like because you crashed or something so so you know.

A

Any other questions or comments on this presentation see so if I go.

A

Okay, the next one is Glade based grouting.

I

Okay, hello, I'm, Julia scrub attract. Did they mention the spelling of my name next so I'd like to tell you you know: can you grow really old? You start taking the things you did when you were younger and trying to recycle them, and so today, I'm going to tell you about something we did four years ago and that I've just asked a for adoption by this working group now and that's joint work with Betty Jean glaze.

I

So there is a company in Paris, they're called Nick CD and next idea running a distributed cloud system, so they have data centers all over the place and what they are trying to do is to build a distributed cloud out of all of those data centers and their original plan was to run over the public ipv6 infrastructure and that failed horribly.

I

The problem is that the public ipv6 infrastructure is not reliable enough, and if you have enough nodes, then the probability that anyone can speak to anyone else is basically zero, and so they came up to me and I said well. Why didn't you put a bunch of tunnels and run some dynamic routing protocol over the tunnels? Okay, so we designed over a restaurant napkin, an algorithm that would allow us to have enough tunnels so that the network remains connected, and then they told me, okay, that's what routing protocol shall we use?

I

I said it doesn't matter, it doesn't matter because since you've separated the tunneling bits from the routing bit you'll be able to change in the future. So why don't you try that? Oh, they said cool, and for eight years now they have been running.

I

Babel and they've had very good experiences with them and wished they'd started with normal, an extended Babel and they were very happy as long as all of their data centers were in France and one day they opened, they set up a new data center in Tokyo, so here's an example topology and that's an actual problem that they saw so that's a little bit an opposite of H Mak H Mac is something that we did because we wanted to do something clean here.

I

We were trying to solve an actual problem that real people have and in this topology what happens when the leading marks a link breaks. The tunnel has broken for some reason, because some ISP have decided that it's cheaper to break connectivity and violate their SLA rather than pay for transit, and you have no connectivity between liliane masse. Well. Babbles is two hops between through Paris and two hops, through Tokyo and so non-deterministically, one half of the time it will decide to route the package from limb to Marseilles through Tokyo.

I

We have nothing against Tokyo, but clearly routing packets from Linton are safe through Tokyo is a bad idea. Next, please so my first suggestion the world's: why don't you put a GPS in every router and then we can use the geographical distance for breaking ties in our routing and they said that's out of the question, that's out of the question and what they told me was that the problem was not the price of the GPS. The problem is the human being.

I

Who is going to make sure that all of those GTS are running at any given time so you're introducing too much failure modes, you're introducing unusual things in the data center? They said that's out of the question, so we decided to measure the two-way delay the rtt and derive a metric from that. So before somebody comes up and tells me about TCP Vegas or led that or bbr or is it B RR v BR? Okay, all of those things that measure one-way delay.

I

I know it's possible to measure one-way delay, but it's more fragile than RT t and it's more difficult to implement and remember that here we are not doing a congestion control algorithm. What we're doing here is a routing protocol.

I

The goal of the routing protocol is to select the best routes, so you are not to accurately model reality as long as you have managed to find the best route you've won, even if your modeling of reality is somewhat coarse and RTT appears to be good enough, at least for this application, and the problem is that the natural way to measure RTT basically pink, requires asymmetric, there's a client and a server and synchronous interaction. You have to answer the ping as fast as possible. Now babble is a symmetric protocol incident, a synchronous protocol.

I

Nowhere in Bayville does it say you have to reply straight away. There are times where it says you must send a packet in a timely manner, but at no point do you have to react in an immediate and the other problem is that using RTT as input the routing metric causes a negative feedback loop which I'm going to describe, which might lead to persistent oscillations. Next, please so RT t RT T is on the diagram.

I

The distance between T, 0 and T and the natural way of measuring it is to send a packet from a client or server and have the server reply as quickly as possible. So first, that's that's asymmetric, that's something we could work around.

I

Actually, there's no big deal with doing symmetric asymmetric stuff within babble, but the other problem is that when the server replies the thing it must answer Punk as quickly as possible and the delay you have between the ping and the pound is what is going to kill your accuracy and now because in babble you are allowed to reply later. You might have buffered some stuff to be sent later, and here you have tricky issues of do I, flash everything right now and cause congestion. Do I rear their packets and cause pathology due to packet, reordering?

I

Ok, it look like a little bit tricky to implement next, please, and so what we decided to do was to use Mills algorithm, so Mills algorithm was done by Mills and it was originally implemented in hello, which was the routing protocol used by the SAS for people who still remember the fast, also either people who are old enough to remember fuzzball or people who, like me, enjoy doing, protocol, archaeology and so there's actually a TLV in babel that is named in the honor of the hello routing protocol and the same algorithm has been used later still by Mills in something that all of you are using, which is NTP.

I

So the idea of Mills algorithm is that you do a symmetric, asynchronous paper. You send your packets at any time you want, and here I'm, concentrating on the second packet, the one that goes at time, T T from the right to the left, and this packet is not just a silly pink packet with no data.

I

It contains three time stamps which are teo, which is copied from the previous packet in the other direction, which is called the origin timestamp TR, which is the time at which we received the previous packet, which is there called the reference timestamp, and it also contains the transmit timestamp, which is the time we're sending this packet. Okay, I'm now be careful, tio and T are, according to the left, peers, clock and TTT r TT are according to the right, Pierce clock, and we don't assume that the clocks are synchronized.

I

They might have an arbitrary offset between them and then, once the guy on the Left receives the packet it confused at a time stamp set with T the time at which has received it and computes t minus T, Oh 12 times on the Left T t minus TR both times on the right makes the difference between the two, and that gives you an estimate of the RTT and that's symmetric.

I

That's asynchronous that doesn't require clocks to be synchronized, and the reasons, on the other hand, are something you must do. You must compute the timestamp at which you send the packet. The TT as late as possible, just before you send the packet not on your buffer and same thing as soon as you receive a packet before you even parse it you timestamp it and that's what your accuracy is going to depend on next, please.

I

So we wanted to do Mills, algorithm, Babel and what we've done was to encode the timestamps and sub GL DS and the transmission timestamp. So the time at which the packet is sent, that's a property of the packet, so we've put it in the hello and that may have been a mistake.

I

Perhaps it should have been simply a TLV rather than a sub TLD of hello and the other property and the other other to timestamp the origin and reference those are copied from the latest packet you received from the peer, so they are specific to a given peer and they are sold as sub charities of the ihe govt. And originally we started with a 10, millisecond granularity, and then dave told us what he thought about it. You know Dave, you know how he tells you that he disagrees like seven times in a row.

I

Okay, until you get it and I wasn't sure, but my co-author batiste said Luke is absolutely right: it costs us four extra bytes and we never know when the extra precision might come up to become out to be useful, and so the granularity is one microsecond next leaf.

I

Okay, no secrets here are 32 bits rolls around every 36 years, or is it 72 I'm not sure about the sign? But okay, no particular issues here. Next, please, okay, so Mills algorithm is going to give you some RTT samples and that's a noisy signal and the signal that is not immediately useful for a routine metric. Remember we are doing a routing protocol here.

I

Anything, that's not about selecting the right route is just noise, we're not in I'm.

G

A bit slow here, Michael Abraham's again, you said microseconds, so you're, counting microseconds, so you're 32 bits 32 bit counter in your counting microseconds nope.

I

Yeah, okay, so what was the 32 I said something stupid about the year about rolling over yes, I did I did I will right so so it.

G

Rolls over much you have to to raise to the 32 microseconds. That's.

I

Right, yes, and that would be thirty-two thousand seconds.

G

It's four billion in /, Our, Lady's, four thousand seconds yeah. It's a.

I

G

I

An hour, and course, unless.

G

You're going in an interplanetary.

I

Well, I suggest I'd suggest we tackle this problem when we have it yeah sure yeah sure I was completely off, so we are assuming here that you send at least a hello every hour. Okay, so you get a bunch some noisy signal, but your goal is to select the routes. Okay and you need to do quite a bit of processing, so the RTT sample that you get or a noisy signal. You do some basic smoothing over there. Then that gives you the smoothed RTT and the RTT is a time in milliseconds.

I

That's not a metric. In order to get a metric, you have to map it to the abstract units that we use for our metrics. So you take your link, cost the one, the normal link cost, which mode is the 96 that you have with normal battle and you compute a penalty from the smooth RTG and this penalty is not a linear map from the RTT of how you add the penalty to the link cost from that. You derive a metric, and here that's important. There is a third mechanism which is hysteresis.

I

That's applied to the metric I'm going to discard all of that next, please so the RTT samples we get or a noisy signal. So that's actual data from an actual tunnel between France and Japan and that's the bad case. The good case is actually worse in some ways. That's the good!

I

That's the bad case at the time when the ton the RTT was very not so that's during the day, and what you see is that it oscillates widely between 280 and 320 milliseconds and that you have a lot of outliers and the blue line is the smoothed data and the smooth data is a signal that you can actually use so note, the horizontal scale, that's 10 hours of sampling, and so what we do is so I think that the actual algorithm you use for smoothing should not matter much.

I

You just want a smooth signal, but we did not do any real evaluation of what happens when you change your smoothing algorithm. So we've just stolen the algorithm from TCP the one that's used for computing, the RTT in TCP and the constant alpha where TCP says, should be between zero point. Eight and zero point: nine: we chose a zero point. Eight three, six and first person who works at Y I'll be very impressed. If you work out why you won't work at F now, you will need at least an envelope next thesis.

I

You want the answer. It's easy to compute with integer arithmetic, where in doing Taylor's is some stuff, that's the whole reef. Okay! Now so now we have a smooth RTT signal, but using RTT for computing, geometric colors, a feedback loop. You know when you were a kid on the highway and it was really hot in the back of the car and the highway was really congested and then the radio would say well, there's nobody on the other Highway and then everyone would move to the other congested.

I

So the radio will say: hey, there's nothing. Nobody on the first Highway and everyone would move back was going back on here is that there is a negative feedback loop, the more you push traffic over a route, the more its RTT increases and therefore the less desirable it becomes, and therefore the less traffic you push over it now. Usually an egg Luke, a negative feedback loop is what you like, but converges because the more you do something the less you do it.

I

But here when we're in a discrete space, either we go to the left or we go to the right. The fixed point doesn't actually exist, so you end up oscillating now, Babel doesn't care even in the presence of oscillations. Babel will push packets towards the destination according to Luke free pass, there's not much. That can be wrong, but if you also like between routes, you might reorder packets and higher layer protocols do actually care. So you need to limit the frequency of oscillations.

I

And the insight came from some old paper from the 1980s, which was trying to use RTT and link-state protocols, and the answer is you want to saturate your metric so instead of mapping RTT to a metric linearly, as you would expect, what you're doing is that you have a range below min RTT at which you consider look. This route is good. This link is good. It doesn't matter how good it is, and above and that's not important. The important bit is that above max RTT, you consider this link is bad.

I

It's really bad I, don't want to use it if I have any choice, and at that point the penalty remains constant and the fact that at some point you stop penalizing high RTT links that this world is going to limit your oscillations.

I

And what you want is that this Max Artie T value is well chosen and this that part of the protocol requires manual tuning next, please now the saturation bit avoids oscillating between congested links, but you might still, if you're in the intermediate range, have two routes that have very similar RTT and they are oscillating around a value and you will end up switching turn to apply hysteresis and there are many hysteresis algorithm. So I worked out this one. So in this one you have in a which is the metric.

I

That's actually announced, and there is a second metric which I called the smoothed metric, which is basically an exponential average, a smooth version of the announced metric so think of MA as being the short-term metric. It tells you how good the route is right now and m/s being a history sensitive metric.

I

It tells you how lot good this route has been recently and when you switch routes, you only switch routes if the new route is better than the old route, both short-term and long-term, and this and there's a symmetry between better and worse is what is going to give you hysteresis and hence more stability. Next, please that's with hysteresis and no smoothing this datum line the pity. So this is worst case.

I

We constructed a diamond topology in simulation with huge amounts of buffer bloat, so buffer bloat is really bad for us, because it means that the RTT is very very widely with nothing to break the feedback loop. So, though those are four bloated routers in a diamond topology, measured over 4,500 seconds, Michael helped me because I'll say something stupid again.

I

That will be about an hour and a half yes, and what you can see is that you have oscillations between the red route and the green route. So you'd have to look carefully at the frequency next leaf, and now you add, the you tune. The metric to have a max RTT value that as well chosen is the dashed blue line around hundred and something so what you're doing is that the links are spending most of the time and they are saturated State. And at this point you pick a link.

I

The RTT of the link increases because you have buffer bloat. So you switch to the other link, but the RTT of the rig will only decrease once the buffers have drained. And then you have the hysteresis that takes some time to take it into account and supplied after saturation and together between the fact that you're waiting for the buffers to drain without measuring the RTT, because you're in the saturated range plus the hysteresis bit. You end up having oscillations that are order on the order of a minute. But.

J

The TAS depend on bubble being scheduled, along with the data right, the firm. If you have like type of service prioritization of the routing protocol traffic, then this will go. Then you have no problem. Then.

I

You're measuring the link RTT without measuring the RTT due to queuing and all of those mechanisms are useless because you're not going to have the feedback loop. So.

G

What he's also talking about running over tunnels- and you might not have the fur to say sure, for the routing protocol when you're running over and it's all over the internet, I think you're looking for deity, they really really worst scenario here. That's already drank more so.

I

I'll put it differently. Perhaps I wasn't sufficiently clear. We don't want this to happen. The feedback loop is a bad thing and it doesn't happen in practice in practice. You're going to have plenty of throughput, okay, you're running over gigabit links. Okay, nobody has ever managed to use a whole gigabit, except perhaps David I'm, not sure.

G

Ok, Michael, yes, so I just want to say about buffer bloat I had to deep load our Giggy you've bi-directional offering, because when I ran I for single TCP session, 100 milliseconds of buffer bloat, if I did not deep load it, the standard configures ask the router to shape at one gig gigabit per second, then the TCP guys have done a wonderful job and TCP will take all the bandwidth and I'll use a hundred milliseconds of buffering.

G

It's great so the one that came default in the Linux distributions that I was using did this, so this is not as silly as it might seem. No, it's not silly! So basically, we are assuming that you run this right. Okay, pathological was, it was probably the name that did what I was using for not silly but yeah. This is this. Can.

I

Actually be a real problem, you know what we want is a protocol that those mechanism are not used when your network is working. Fine. What we don't want is a catastrophic mode of failure when your network happens to trigger this thing. Okay, ideally, of course you don't get the feedback loop in the first place, and you have no problem.

I

Okay is that yeah? Next, please, okay, I'll, tell you the whole truth: we've done some really bad science. We wanted to have a solution that worked. We ended up. We had only a few months because that was effects your internship and we did not at the time work out a complete understanding of. What's going on, we did an engine engineering job instead of doing a scientific job.

I

That is, we did manage to get something that works beautiful and that has been working in production for eight years now, but we did not actually study all the trade-offs and we don't fully understand what's going on. So there is one minor issue in the packet format, which is that the IH? U sub TLD, can only be interpreted if the packet contains a hello. So remember, there are three timestamps and two are carried by the HU because they are per peer and one is carried by the hello.

I

So that means that, in order to interpret the data in the HU, you need to put a hello in every packet. So that requires some inter TLV scheduling in Babel and that's something I really dislike. So I wrote it and written an alternative here, which is to include the transmit timestamp in each HU, but that causes a different problem. So remember that you are time, stamping the packet as late as possible. So what we do is that when we buffer there hu, the hello, we put a and sub TLV in it.

I

At the very last moment, we patch the hello with the timestamp and that's fine, because there is only one hello in the packets, but there are multiple ih use and if you need to patch it multiple time the implementation will become more complex. The other alternative that I didn't write here. Ins, which I actually like more, is to use the timestamp on the hello to you, the timestamp, in a dedicated timestamp TLV, rather than attaching it to the hello, that's something we will need to discuss and we did some Mike.

G

Robinson again often or the hellos typical sentences, every every.

I

Four seconds.

G

For second, by default,.

I

Okay and the minimum value is supported by the protocol, is 10 milliseconds.

I

And what we did is that we did do evaluating of the interesting bits like why saturating is important, but there are some things that were: we did not do our job at the end, we didn't evaluate what happens when you change smoothing functions, that's something that doesn't bother me much, because the answer is pretty clear. Nothing much will happen, because this new thing is not important.

I

Bad things happen in this protocol. If max RTT is too large. If max RTT is too large, you get oscillations in the bad cases and we didn't do any work on auto-tuning max RTT, which should be doable and I. Think that's our greatest sin. We didn't fully evaluate the effect of hysteresis and how the hysteresis should be tuned.

I

So it's obvious, you need some form of hysteresis, but whether we've done the right thing, that's not clear at all next please, and that is the reason why so what we have here is something that will be beautiful in production, we'd like to get it standardized and the packet format I. Think, is something that we understand. We understand the trade-offs, but in order to make use of it, you have to use a bunch of algorithms and those alder is are not fully understood.

I

So what I would like to see would be a situation which we managed to standardize the package for and an enormous part of the document. Just say: hey folks: that's how you measure RTT and babble. If you need RTT and what you use this RTT for I'd like to avoid standardizing, because I don't think we're ready to standardize that and just have an informative, appendix saying: look, that's what we've used it for it works pretty!

I

Well, okay, you might take inspiration and we would like to do more research about the algorithm that, of course, no eta for that, because if there is always other stuff coming out, thank you for attention.

K

David's Knaus e google thanks joyous first point: I, really supportive of this work and I do think it should happen here. I'm, really glad that we have one like actually deployed extension like this, which really reassures us that the extension mechanism in Babel all works. So that's a great use case that we don't were shipping, something that we know is solid and now a question have you just out of curiosity? Have you tried running this in babel d running both the one RT, the rtt extension and h mac, and how does that impact timing.

I

It doesn't work, it doesn't work due to a limitation of the implementation. So remember that, in order to make this work, you need to have a hello together with every I hu, so the timestamp will be ignored if an I achieve is spent in a packet that doesn't have a hello now. Remember that will DTLS the H.

L

H

I

Mac we haven't with DTLS, it doesn't work with H Mac. We have it, we haven't done any testing. There is no reason it shouldn't work, no incompatibility with H, Mac and.

I

All right impact the timing because might impact the timing, but that's just one passive hash and over the packet, but that's a cool, a good experiment to do. Yeah and.

K

So it might be worth just adding somewhere in the document that it doesn't work with GG awesome say why, because I think that's.

I

That's the implementation. Does the implementation? That's not the protocol, because nothing pretends it prevents you. Oh yeah, unicast, oh because.

G

They think you.

I

Have unicast hellos and you have unscheduled hellos, so you don't even need to do anything complicated. You have the unscheduled hellos. So now it can work with DTLS over unicast, oh cool.

K

What maybe, explaining how to do that could be a nice of that Dex or something.

I

I'd, rather we didn't explain it until we did it.

A

Are there any other comments, questions so there's a call for working group adoption that was it I was posted which ends at this meeting and there's been strong support on the mailing list and no opposition. There are anybody in the room that's supposed to adopting this as a working group draft hearing, nobody, it is so adopted and all set ask the authors to post the zero-zero version as a working group draft. Thank.

I

A

By the way, if there's is there, anybody who hasn't signed the blue sheets and maybe I can put their hand up or we could get the blue sheets to them, but maybe there everybody has signed the blue sheets.

A

J

A

Don't have boxes, they have X's that okay.

M

So the information model it is in W GLC, which means.

A

M

You're as bad as Aaron- oh my god in the Pecha Kucha Aaron, was like forwarding my slides before I was done with my twenty seconds and it was so wrong. Okay,.

A

Where I had to advance the slide right.

N

You know get twenty seconds per slide.

M

Okay, so um anyway, we have been Mahesh and I have had a great discussion at least I. Think so um I don't know how much.

M

And we've been doing it over on github in my github site, where I've been trying to keep editors drafts and things like that, I have not but I know I promised I would I have not put the updated broadband form data model there I just sort of ran out of time with everything else. I was doing this week, but um it's in good shape. I had great comments out of broadband form as well so major changes.

M

Clearly we did some stuff on hmm some stuff on DTLS I, put in the statistics and message that we agreed to coming out of Bangkok, and there was also some additional discussion on the list that helped me clarify some stuff I thought that was great and the other stuff out of Bangkok I did okay.

G

M

I've got the rest of the slides, are about some issues. I would really like to get some input on number one. Do we have the link types registry? Do we have the right names currently in the registry and is it meaningful to describe what sorts of links it is used for, and is there any idea on how extensive the list should be now Julius has previously said this is I think you really only want the main four and then we can leave some room for experimental stuff at this time if they want it.

M

Mahesh and I have discussed that in fact, now that we understand better, that Ethernet isn't really just Ethernet, but it supposedly incorporates everything that's wired, including all of the no new wire protocols like powerline and mocha, and things like that. We're really confused and wondering if we should change it back to Wired or Julius.

I

So if you look at the Babel, the implementation you're going to have a lot of per length tweaks, are you going to use packet loss for computing? The metric? Are you going to use RTT for computing? The metric? Are you going to use, split horizon and so on, that's impossible for a normal human being to chip, and because of that, we have bundled sets of parameters into names that you can give to the actual users who don't want to understand all of the details.

I

So, for example, wired means no link, quality estimation, no RTT and you split horizon. Okay,.

I

I'm not very keen on inserting things that don't have clean, mappings or clear mappings on to the algorithmic level.

G

So my cobraman, so instead of inferring these properties, don't you want to model them for those properties instead, instead of trying to create it, is this going to be used for that? Don't you want it.

G

There isn't an eye on a link type list of FDI in a Volvo, but if we're modeling properties here shouldn't, we put the properties in here instead of having you know, Ethernet, to mean something so.

M

In other words, maybe under the used for links defined by describe the properties of the links that you use, these names for.

G

Okay I mean if this is the reason why worse, the.

L

G

Is because there are table properties, then put the properties in there. Instead, oh.

O

G

Making up something in inferring from it: okay,.

I

The question is: do we want to be exporting something that makes sense, or do we want to be exporting something that the users have a chance of understanding and that's a difficult call? No.

M

I think we can meet both. Actually what I'm hearing is. We should not use the term Ethernet. That's really confusing.

M

The description should be really about the properties of the types of links, and this should be I, don't know. Maybe the names can be more esoteric to meet the description or to characterize that the grouping of link characteristics, Benedict.

O

Wong I would agree with that in that for wireless, maybe I'm not sure whether Babel is considered over some of the networks, but the RSSI kind of thing, for why? For the standard Wi-Fi and over a cellular network will be very, very different.

M

Okay, I think I've got a way forward on this and I understand better, and we may actually change this from a link. Type 2a link properties type just so that we get it completely out of the people who are thinking of the Ayana if' list.

M

Yeah cool I hope you've got that on the the notes. I read: oh my god. Well, hopefully, you know the Medeco recording will work. Okay, hmm DTLS interfaces modeling um had some discussion of additive interfaces. Oh good Michael's leaving us.

P

M

Said one hour go away: okay, um now, Mahesh and I were discussing and actually I got some input in broadband form that we should actually change the direction of the reference right now. I was trying to reference two interfaces from H, Mac and DTLS, but it's been suggested that it might really solve a whole lot of issues if we change the direction and from interfaces reference to H, Mac and DTLS objects, and that would actually match more closely with what Julius was describing on the list as to what you were doing.

M

If we do, this I still need to consider where to put the global, DTLS and H Mac parameters in this decision, because I'm pretty sure that, like the use of the cached info extension, we don't want that to be kind of a per interface decision.

M

It, but maybe I don't know, and that would be a useful thing to get feedback on similar to this server certificate type extension and those are the DTLS things and then on the H max side, we've got whether the verification of received packets is enabled, and the question is you know if we move the direction of linkage, should these things be considered interface specific or should they be global and.

M

Nobody's going to help me answer that, are you, okay, with changing the direction of the reference, because it matches more closely with what you described: Julius? Okay! So the other question that.

A

You noted that Julius nodded yes,.

M

Thank you, Julius nodded. Okay, it was not nodding off. That was an actual responsive nod. Yes,.

I

Okay, dubious crap attract the question here is whether an security credential refers to an interface or an interface refers to a credential, we're.

F

M

Of Prudential there.

I

Is a disagreement between my implementation and information model and they're trying to work out whether I'm, wrong and Barbara's rights, or whether Barbara's I got confused? No we're.

M

I

Only one we should agree on the direction of the reference in one way or the other and.

M

Everybody is saying that we should reference from the interface to this set of potentials.

I

M

That's what good that's, what you nodded about and I agree with you completely and that's what my colleagues at broadband forum said too. So it's like everyone agrees that Barbara is wrong: okay, okay, but now the the other question I really have is about. Are these other parameters global or can they be associated with the set of credentials.

I

Okay, verification of receive packets. That's clearly you want that to be per link. You have a secure, router you're, adding a new link. There are unsecure Reuters and this link you want to transition the new link. You don't want to disable security and all the other links just because you've added a new, insecure link. Okay,.

M

So on the H Mac, it can be associated with a set of credentials that the link points to.

I

Or I would say it should be associated with the link. It's the interface itself.

M

I

M

I

A set of credentials, it's on all of your interfaces, you're having a new interface and you're, adding this new interface incrementally so, basically,.

M

These parameters.

L

Get added up under the interface so.

I

Just go to the interface.

M

For H Mac, okay.

I

This specific one, you've quoted, which is weather verification of receive a the packets, is a name.

M

Right those get added that goes to the interface okay, Mahesh.

H

Aeternam Donnie um I think we should try to answer the question of which end phase refers to Detailers H, Mike object or the other way around is by asking the question: do you have one interface that they're first, the multiple VPLS /a track objects or that you can have a given DTLS /eric object being used by multiple interfaces?

H

What is the case? I think.

M

I think a single DTLS can be used by multiple interfaces and that's highly desirable, because we want there to be kind of a default or to be able to use a single for everything yeah the, but the other one that Toki did bring up was. It would also be desirable to have a single interface, be able to point to multiple objects and I think we can have both its and and for H Mac. It's once we pull this global parameter out.

M

I think we're fine I now need to, though, understand the DTLS, whether they the detail s, things are global or are they linked specific or your? Your walk? You don't look convinced I'm, sorry,.

G

I

G

I think it's hard to do that here, but typically you want to have a many-to-many, so an interface can have many something, and this this thing should have like a name that you reference it by they've. This credential like an SSH key, if you're doing that or so on. You should be the have that flexibility, because that always comes up sometimes later I would say that you wouldn't want to do something like that.

M

We'll get to names later, okay, so if the DTLS people could kind of think about, are these DTLS parameters global or would they be kind of link specific? That would be really helpful.

M

Yeah they're, not gonna, answer me today, but I want an answer and if you don't give me an answer, I'm going to make a decision- okay, name for DTLS, cert and H Mac key- and this is more informative, because Mahesh and I have already agreed on this.

M

We're going to be naming these things so that they have a unique key that you can refer to them by, because there's really nothing else to refer to them by you're, not going to refer to a key by its value.

M

M

M

So we've also taking one step up. That was the that was the the this was about the actual certificate and key, but one level down. We had these objects and some of this yeah, where we're trying to figure out how to refer to these H Mac and DTLS objects that contain keys, multiple one or more keys and Mahesh and I had disagree and on where to specify the unique key, because in some of my modeling that I do on the broadband form side, we have auto-generated things.

M

If you don't specify a unique key, so I don't know, need the information model to do something for me necessarily and so I think Mahesh. We kind of agreed that you can just specify something in yang. If we don't do anything here, does anyone else? Oh Julius does have something too.

I

M

I

Hash of the content.

M

I

M

I

Even simpler, why not use the key as their identifier itself a fingerprint so.

M

Okay, so that goes back to this one. This is a specific certificate or a specific key, and that's.

I

A human, readable name.

M

It can be it's it's the information model at this level. It doesn't care once you get into a yang data model or broadband form data model. They do different things or even, if you're doing some other way of data modeling it. Those things are going to care, but it's left up to the data modeling mechanism and not dictated by the information model.

M

In this case, we're saying that we do need some sort of name we're not specifying the syntax of the name, but it cannot be the exact value of the certificate or of the HMS think I understand three.

I

You don't understand four okay,.

M

Four, we're going to need. There is inherent in the information model as currently specified. There is nothing you can point to. That is a unique key, and so what I'm saying is we're going to leave it up to the data model, to figure out what's the right mechanism within the context of that data model as to how to uniquely identify these entries.

I

Okay, you'll have to explain that to me offline.

M

Or over beer, it might make more sense of Revere beer.

I

M

Okay, I think Mahesh and I are fine and I'm really more concerned with Mahesh than I am with you. Julius.

G

Okay, so if you go back just what does unique mean.

M

G

There is this unique is that this thing can only occur at one point in anywhere, or was it mean what unique piece so.

M

When you're looking at a set of objects, you need to be able to address the object that you want right. You know like if you've got yeah, and so that's simply, what we're saying is. How do you address the object that you want and in all of our other things you know like when we've got their interface lifts? We have a unique way of identifying the interface.

M

We have a unique way of identifying the route according you know, to the IP, prefix and stuff, but when we got to these tables there was nothing and so we're leaving it up to the data model.

M

Okay, metric parameters- oh yeah, okay, so this is this is how Oh Christian you have something to say. Is it on the last one? Oh.

Q

M

Sorry, Ronald I'm.

Q

Sorry yeah I just have to say that I'm failing miserably to capture this discussion because I'm not at all familiar with the information model, don't worry about.

M

It yeah I, appreciate it and you don't have to record that either.

A

We're not too short on time yet, but we are, is gonna, get some fun.

M

I've only got two more issues.

A

M

Then we're done um in this one, it should be a quick one, and this is something that kind of came out just in Mahesh in my recent discussion, and so we figured we just toss it out here we have this the the route, the calculated metric and the received metric, and we previously had input that we have to have one of these.

M

But the question that wasn't clear in my mind, is: are they mutually exclusive or is it possible to have both of them.

I

You really want to have both you want.

M

To have both you.

I

Really want you.

M

You must have one, but it's okay, to have both for.

I

Debugging for debugging problems: you do want to have those you, so you.

M

Must have one having both as desirable perfect, that was quick, okay,.

M

Okay, so in this this is this is a personal problem. This actually didn't come up with Mahesh and I just wanted well, actually it sort of did I just wanted to be absolutely sure that when we reference an interface that it can from our interface list, when we reference some other interface, where this interface lies, it can be at any layer, physical layer, Mac layer, IP layer, tunnel IP. We don't care what layer that interface references.

M

The lack of people coming to the mic means we don't care. Thank you. I have my answer.

M

So we have right now when I look at the implementations, you know they're referencing, something like eath. You know Linux ETH, one which generally in ETH one has the full IP stack on it. It's really not the specific ethernet layer. It's this thing with all of these IP address stacks on it. If we had say in Linux the ability to reference the 100 base, T interface, would that make sense or are there layers that don't make sense of interfaces? No.

L

Because babel runs over.

I

L

I

That you want to be referencing the layer, 3 objects.

M

Exactly my question.

I

However, and the fact that babble is using lower layer information, it's very carefully designed, so it's only an optimization in that we reference the layer, 3 object, and if we have access to the layer, 1 and 2 thingies, we can use it. That's. What is fundamental. Is the layer 3 object? Ok,.

M

And I think that answers my question because both yang in broadband form, we basically stack our interfaces and so you've got. You know. Here's an ipv6 interface in this ipv6 interface by the way happens to ride on this Mac interface, and this Mac interface happens to ride on this physical interface. And so you know your interface stack. But the question is at what entry point we're we're in the stack? Should you be pointing and you're saying, I need to be pointing for the ipv6 answer.

I

I need to know the link local ipv6 SS, so.

M

I've got we're good, we're good I've got my answer. Thank you and it was not. The answer. I was going to go for if you hadn't stood at the mic, so it's a really good thing. You got up there so we're in wgl see additional review would be really great in the meantime. We just here just result just about every single one of our issues, I think so I'm going to be revving the information model based on this and we'll do the Yang and the tier, 181 and I think we're in pretty good shape.

M

A

Yeah, that's fine No! Thank you very much. So there there is a working group last call, but as you, there hasn't actually been much response on the mailing list, and there are these issues, though, that since the documents gonna be read, well, let's continue. The working group last call next is.

C

E

Get out of this name.

D

A

Then the magic one.

H

So Julius, if you were concerned about the number of Z's in your name, we couldn't exchange some agencies together.

H

All right, the status of the document it is of a group document, as Donna has already verified. We did manage to augment the routing management interface as re RFC, which brought us support for addition of Europe. The vrf instance is something that is now available for us to also add. I haven't quite done that as yet so in the next Rev I'll take care of that.

H

So with the changes, the the model now looks something like this. As we say: I'm augmenting, routing, 83, RFC, 83 49 in as per percent, we have now H back and DTLS port, which we have added to the yang on at the bottom. Is the addition for web and rip support under that so issues so much like Barbara I also have my own github, which is tracking all the issues related to the data model.

H

This discussion I think we have had so I'm going to can skip over this because I think we're going to come back with a proposal on how to really model the link type.

H

So Barbara and I had to go back quite a bit on this discussion of mandatory values and I. Finally, after several attend and a good breakfast, we find Barbara explained to me that the two attributes that she's trying to address one is mandatory to implement, which is not what this is about. Slide is about and there's mandatory from a model perspective as far as values that need to be provided for the protocol to work correctly.

H

So I don't have a slide on mandatory to implement, but just I'll just say, I'll wave, my hands and I'll explain this. Maybe in in the model, is that we need some capability of a feature statement which allows and implemented to declare what features they supported and I and an example of that feature would be I support, DTLS capability or I support, H Mac, and once you declare that feature, then the model it's expected to have all the capabilities defined.

H

If you don't declare the feature that part of the model pretty much vanishes, and you don't have to worry about trying to implement that, so that's mandatory to implement so now mandatory as far as values that need to be provided um so I think in this particular case, what I've highlighted in red are two parameters which I believe are mandatory parameters in what happens is that when, when you do specify that something is mandatory, when the client tries to configure the Rueter or out of with that information, if those valadon exists, the client won't even be able to send that config request to the server.

H

If so, it's the client is not good enough. It's not doing a good enough job. The server will definitely check and return an error saying you have not specified the mandatory values.

H

It also means that this, the scope of mandatory nests is limited to the parent. So in this particular case, the two parameters that are highlighted in red are mandatory only if an h mac is being specified, because if it's mac is not even being specified, then it doesn't matter whether there other parameters within which, within that that are mandatory, the other clarification was around read-only attributes in the information model in yang. Typically, it doesn't really make much sense to declare something: that's read-only mandatory, so something like Rooter or outer ID that Bible uses is read-only.

H

Attribute means it's set by the system, so it doesn't make sense from I'm a config perspective to say well, brother ID is mandatory if it is not said, there's nothing that I.

I

Can do and if I read the Rooter ID can the answer be the earth known.

H

A proper implementation will make sure that it is always said, but yes to answer your question, it is possible that if you read and the implementation hasn't done it right, you might actually get nothing back for it right. I.

K

Think what Joyce is trying to say give its Knaus e I think what Joyce is trying to say is that you can actually have an implementation of Babel that does not have a router ID. That is just a like simple client node on the edge that doesn't offer any routes, and so there it so that it's valid for that to be non-mandatory.

K

H

Then actually I don't know, maybe the information model, then what I'm gathering is that it's not mandatory.

M

Right, which also means you can't use it as a key.

H

I

It's not quite clear, so does it make sense to put restrictions on the implementation? Does the management model put restrictions on? Is it legitimate for the management model to put restrictions on the implementation, so it is technically possible not to have a Rooter ID, but it doesn't cost much to say we always have a Rooter ID.

H

Okay, so so let me back up the the reason why Barbara mentioned Belleview, it can be a key is because currently we reference an instance of Babel by the rotor ID, and if the Rooter ID is not there, then we have no way to reference.

I

Not shocking, but so, but my question was actually more general because that's a detail we can bring to the mailing list. Does our Oh, so our o implies that there is no way of saying it must be presence. Is that.

Q

H

I sorry, there.

M

Are other ways we're saying it yeah.

Q

M

In yang ro does not imply that there are other ways: yeah.

H

What I, what I mean to say is that it's not enforceable I mean you can have it in the description and you say: must you must provide, but.

H

Alright, so we have had discussion of keys on the mailing list and I, don't know where this discussion sorry.

K

Just a quick last point on the router ID I just checked the 6126 base and the spec explicitly says that the router ID must not be either all zeros or all ones. So if this makes your life easier, you could, if it's not there, have it return all zeroes, for example,.

H

Well then, the question is: if can multiple instances of the routing return, zeroes all zeroes, in which case then it's not unique again. True.

K

Yeah and then, but like those instances that don't have a router ID are just gonna, be kind of observers. They're not they're, gonna, be like almost invisible to the rest of the network, so now being able to refer them is kind of okay. Oh no.

M

It's not okay, no.

K

It's not okay and Julius is shaking his head. So forget what I just said. They.

I

Don't appear as originators of roots, but they might that feareth neighbors so still see them. So.

M

Y'all are thinking of this from the network perspective we're thinking of this from your inside this box, and you need to reference the information. If you need to reference, the information is there, can the router ID be a key into your object model or not, and what we're hearing is not.

H

I'm glad you're forcing the decision no.

I

What we're hearing here is that the natural data structure that is used by babo says that you only need to have a ruler ID if you're originating groups, if the data model needs to say that implementations that implement the data model must generate ruther ID, even they don't need us just for the routing part I'm fine. With that it'll cost much to generate 64 bits of randomness sure.

H

Okay, so that then answers our question of how we need to update the information model and I'll reflect that in the young one yep, thanks for the clarification, okay, so I'm, not a security expert and I just go based on what is there and some of the be remodeled. So my effort is to try to just bring attention to the fact that there are other data models that we have to deal with as far as he setting up keys, key exchanges and everything related to that.

H

So there is already an RFC for symmetric keys and how to store them and how to use them.

H

There is a draft on the asymmetric key and certificate support that is in the works in the net count working group, but none of these, of course, have any thing that supports key rotation. I, don't know if that's important, if that's important, that I, we need to figure out how we will support that and then I think this is the question I think Julius brought up on mailing list is: how do you share keys across domains as H Mac uses, symmetric keys?

H

So I don't know if these are issues but I'm just keeping it there so that we don't forget it as we try to progress the draft either we decide it's, not an issue and closed them or we try to come up with answers.

H

No update on the routing policy and augmenting the routing policy model I'll do that in the next version, and my final issue is with example, configurations. I really could use some help here.

H

I would appreciate trying to get some configuration examples that I can use not only to validate the model, but also showcase to people who want to use them on how it we configure. So if there are different implementations of the model that have different ways to configure I would be I would imagine that would be very, not very kosher, but if it is the case, let me know, but basically I would appreciate some examples that I can use for validating the data model.

I

What you're asking for are examples of real configurations in the current ad hoc configuration language of our different implementations. Is that correct? That's.

H

Fine, you give it to me: I'll, do the translation of that into what would be accepted by the data model, and then we can validate to make sure that the example makes sense.

M

Right so it's mainly wanting real data, but it doesn't have to already be in the yang syntax. It's that's.

H

Good I can do the translation to the yang syntax, including.

I

H, my H, my keys, of course. Yes,.

H

That's what is far afield configured.

A

Alright, that's it! Okay! Thank you very much. These are actually out of time, so people should help Mahesh we're getting things he's asking for I'll.

A

You can post something to the list to asking for that, also or if you don't I'll I will maybe when the minutes are done and stuff. So thanks.

Q

G

A

I think we're making great progress. We have a big package of documents already in publication, requested State and more documents coming along, so see you all on the mailing list and this Montreal with the next IETF meeting I think anybody have anything else. They want to bring up I guess not if you did not sign the blue sheets they're up in frontier, please come and sign them. Thanks again,.

R

R

So this is the one that hooked to the projector. Okay, I reloaded this okay.

C

G

Just download my flashlights yeah.

R

R

It's yours! Oh yes,.