Internet Engineering Task Force IETF 114, 28 Jul 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF114-DNSSD-20220728-2130

Description

DNSSD meeting session at IETF114
2022/07/28 2130

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

A

All right we're gonna, wait like two three minutes to leave some time for people trickling and then get started.

B

And in the meantime, if you're not um on the meat echo, then please scan the qr code.

A

Yeah, do we have volunteers to take minutes and or jabber scribe.

A

Thank you, stuart much appreciated.

A

Can anyone be the jabber scribe? It just means watching on the scribe and if someone says make colon you relay what they say at the microphone.

A

We'll smile at you to thank you, you won't see it through the mask, but I promise I will.

A

I thought I can do that. It's a very low effort role these days and can we have a backup to take notes from what stuart is saying when stewart goes up to the microphone? Who would be willing to do that? It's a collaborative tool, so you could just add edits and it works really well.

A

It's funny I've never seen everyone look at their email so intently than when I'm looking for a minute taker yeah. Well, let's look at the remote people too, see who's in there.

A

Thank you so much.

A

Most centerpiece of the thing is bottle.

A

Yeah looks pretty gross actually yeah.

A

A

What's going on stewart.

A

All right, yeah, sorry, we forgot to copy the agenda in there. My are bad um sure. Should we get started? Yes, all right, hello, everyone and happy thursday. uh My name is david skenazi, and this is chris bucks and we are here to talk about dns service discovery.

A

This is the note, well note it well, um this is thursday, so most of you probably have seen it before, but in case this is your first meeting. We want to insist on a little bit you when it, whether you're registered in person or remotely you agreed to this note well and if you haven't read it before, don't try to read it off the slide. The font's way too small, but it really matters into what we do so, for example, when you say something or type it in the chat or on email, you it it.

A

It triggers some requirements with regard to intellectual property, and it also says that you agree to follow our code of conduct, luckily that we haven't had issues in this working group, but I just want to talk about it to guarantee that we keep it that way, all right next slide. Please uh also a reminder for folks who are in the room uh at this. Itf maxx are required and you have to wear one of those fancy certified ones.

A

um If you don't have, if you only have a cloth or another one, they we have free ones by the itf uh registration, and the only exception is, if you are actively speaking up here at the chair desk or at the front uh under the anvil there, um because we're far from the rest of the room next slide uh we've. So thanks, stuart and dave for taking minutes and who's doing jabba relay oh, I am right. I'm sorry, I'm very tired. It is thursday uh next slide. Please!

A

All right here are some useful links. If you're seeing the pdf on there, don't try to click that screen next. uh Similarly, we have a github organization um ted. We should sit down uh virtually at some point to get everything on github on there that'd be nice, but maybe not for the ones that were about to send to the isg, because they're almost done, but for the new for new adopted work. I think that would be nice uh cool next slide.

A

uh So an update on our currently adopted working group documents, so the srp draft has been in working group last call for a year to the day. Actually- um and those comments were addressed two weeks ago- so we're going to chat a bit about that and hopefully start a second work group last call and send it to the iesg in the near future.

A

uh The update lease document was adopted a little under a year ago.

A

We had the comments during adoption were addressed, the that's not a whole lot of revisions, but it's a pretty short and simple document, so we expect it to um be ready to progress as well and we'll talk about that a bit and, of course, if anyone has objections, we'll give you an opportunity to say so, and the advertising proxy document was adopted last august and then some comments were addressed and that one still needs to work so that we'll discuss it in the working group all right next slide, and then we have some individual drafts that were published last year and some of them were updated right before the draft deadline.

A

So we can talk about those, and one of them is expired, um all right intentionally all right, so we can remove it from the uh from the list. uh We can talk about that one later. uh Our current agenda is kind of going through these drafts in order.

A

I realized that we kind of tweaked the agenda a little bit talking with ted and we forgot to update this slide, but uh talking through the working group drafts their status then through the ones that ted would like to see adopted in uh the nearest future and then some open discussion time. um So would you like to bash the agenda? That is not on this slide?

A

Are we missing something.

C

So uh I had suggested that maybe we want to talk about uh unicast's dnssd, but if time allows, but I don't know if that needs to be explicitly on the agenda.

A

Yeah, that sounds great.

B

It is on the agenda that is listed on data tracker, so we do plan to cover it. Yes,.

A

Cool next slide, please, uh oh right! Yes- and I forgot to mention in the agenda that we had a little presentation from our area director eric about a newly formed dns director. Tell us more about that. Eric well.

D

Actually soon to be formed, so next slide very quick, so tim wichinski, you mostly know him the chair of deprived and dns.

D

uh Let's make some stats by looking by the word dns in the file name for the internet draft, as well as in the abstract, about 59 of was cash since april, including three, no surprise from this working group, but as well from others. So next.

D

These are basically non-working group documents right so not yet adopted, and in some case it is nothing to do. If you look about the the potential like a group name, it has nothing to do with dns of the private dd or the nssd.

D

So we may assume that the knowledge, the dns knowledge of the people in those working group is not as high as in this room or other room like dns hop. So the fear of the ign we have seen is we received document that has gone through working group. Last call working group last iatf last call arrived at the isg and then we spot some dns issue.

D

It's a little bit late in the process. So what we want to do is recreate a dns directorate so that any working group based on the chairs of those working group can request an early review by the dns directorate. So next slide.

D

So we got a meeting uh with add dns of dnsdsdn and deprive shares, plus the isg and a couple of the two meetings actually to create this dns directorate.

D

Next week or a couple of weeks, we will be sending an email to the community, including this working group asking for volunteers to be reviewers early reviewers.

D

Of course you will not review all documents coming out from any working group. Only the one, those working group thing there is a dns there, a fully qualified domain name, local or or some reliance on dns and like in older iterate. There will be reviewers.

D

We are looking not only for expert and I'm looking about the two dns mdns expert there to be at least one of the two right, because mdns is special, especially really, but also in operation in privacy and so on, as well as junior people right. The aig really wants to get a pipeline of talent, so one way of growing talent is start as a junior reviewer. Perhaps your review won't be the most perfect one, but you will learn how to do it and learn by mistake.

D

You need to learn on the job, so it's a point to everyone around to marry and myself. We will basically select those reviewers small group normally, and we are also looking for two secretaries, so tell the people they say. Oh, we got a request from working group foo, which is the next reviewer. So it's a kind of a clerk or bookkeeping thing, a misrative thing that you do once a week typically and you select the right reviewer and that's basically this.

D

I don't know unsure whether they are questions but basically there's a call for a volunteer. I will send over and we'll send an email end of august about this after the vacation. Okay, thank you.

A

Thanks thanks eric does anyone have any questions for eric, and I want to underscore the point that, like you, don't have to be the person who invented dns to be on this directorate, knowing a little bit about is purely sufficient and it's a great way to know how atf works and to see documents that you might not know. So, if you're interested or have questions uh talk to eric he's very nice, he is all right. So, where.

B

Do you want to drive the slides.

C

uh Let's, uh why don't we try with you and see how it goes.

C

Because I always have trouble regulating my breath when I'm talking into a mic with a mask on, so I apologize um so first we're going to talk about document updates next slide.

C

So the main document that the working group still has has uh outstanding for a long time is the srp service registration protocol document and that document was in pretty good shape. When we did the last call, we got a couple of additional comments um and I took kind of a long time to get it done and and um while I was working on the final update um actually before I did the final update, I updated the tsr document and I realized that there were some terminology problems with the srp document.

C

So the first and fairly substantial change. The srp document is just changing all of the sort of like server client service zones. Things like that. Getting that terminology correct some srp clients are now requesters. Srp servers are now registrars, srp, request or srp registrar, depending on where you look and that just reduces the confusion. There are a couple places where we talk about dns update clients, those are still called dns or dns update requesters. I think, and then dns servers are still called dns servers.

C

um So and then I noticed when I was doing the update that the text that describes the discovery of browsing domains was wrong, so I fixed that that was just me. Nobody commented about that in the last call. Unfortunately, we're doing another last call. So if anybody thinks I'm wrong about that, they can correct me and then there were just a couple of comments from esco about.

C

Suppressing unusual unusable records, which is something that came up when we were talking about the advertising proxy and also clarifying the service discovery instruction section he found kind of unclear. I thought.

E

It was perfectly.

C

E

F

C

But uh but he had some suggestions and I hopefully it's clear now, so we still need esko to tell me that I actually got it right and we may do another cycle on that and the chairs.

G

Have already decided.

B

We need a working.

C

Group last call so um any questions about srp nobody's coming up to the mic. uh Next slide.

A

So hold on before we move on just to confirm for everyone. The uh working group last call has been kind of going on for a while, and a lot of folks have forgotten about it, and I wouldn't blame anyone for not remembering what they said. A year ago, uh it's been a while, so we're gonna officially have a second working group last call the really for a real last call. That's gonna like we're.

A

Gonna start it very soon and last for two or three weeks, and hopefully, if everyone can take a look, especially like these terminology changes. I know every time I do replacements like this. I get one of them wrong.

A

So please take a look and then assuming that um esko was okay, because he had some comments before and no one has some serious comments, then we'll send it over to the isg, and so, if anyone has any concerns with this approach, please say so now or doing the working group last call all right. Thank you.

A

C

Now next slide: oh yeah, there we go um yeah, so the other, uh the other document, um that's sort of close to or hopefully at time for wglc is the update lease document um again. The terminology change is a little bit more restricted here, because the update lease document is not actually an srp document. So we don't talk about srp requesters. We just talk about dns requesters dns update requesters.

C

um The document was um it's been around a long time and when I was reading the document- and I I saw we did actually get some comments. You guys said there weren't that many comments, but we did get a couple comments and- and the comments seemed to largely be a result of failing to understand the behavior that was being described. So I tried to sort of organize things a little bit differently and talk about like the server behavior and the requester behavior for each type of message.

C

The update message and request message are actually the same message just in a slightly different context. The initial update is obviously the initial one and then refresh messages come later, um and uh so there was also a question about, like you know, disambiguating whether like like the behavior for refreshment messages was was was explained as being different than the behavior for update messages, but that assumes that the uh the server knows that it's a that. It's a refresh message, because there isn't any signal in the message that it's a refresh message.

C

So um so there's some text in there that just kind of clarifies that and talks about like well. You know if the server knows it's a refresh message. It should do this, but if it doesn't know, then obviously it can't it's going to just see it as an update message, and this is what will happen if that's the case.

C

So hopefully that's clear, but you know if, if folks see that- and it's not clear to them- please obviously bring that up in the last call, and there was also a question on the handling of the keys key lease interval and I updated that somebody asked whether there should be iana considerations.

C

Originally there weren't iana considerations because the eds zero option has already been registered. However, the registration for the edns zero option is actually not consistent with other eds zero option registrations, and so I added an in a consideration section that just like fixes those inconsistencies um and also requests that the the entry refer to this document and not to draft sakara update lease.

C

um So uh thanks for the folks that reviewed this- and um I claim this is at least ready for last call in the sense that you know there may still be more things to do, but a last call will hopefully catch them. It's not so immature that that's going to be a problem.

A

uh Oh sorry, we had a uh meat echo failure right here. um Well, while chris tries to fix that, um I think if you start sharing again it might work. Oh no, you or just oh, no, it's working um so yeah from the church perspective.

A

This draft has gone through many revisions, but we're not, you know, required to go through many revisions. If it's something simple, and so we think that a working with last call will be a good way to get people to review and flesh or hash out any remaining problems.

A

So we're going to have a group last call that has the same duration as the second one for our srp at the same time, because it makes sense to page both of them into memory together, and we ask that folks, please take a look we'll want at least a few reviews before we progress this, to make sure that we catch any mistakes and then we'll progress them to the ahd, and if anyone has any concern with that, please come and speak up now or during the working group.

A

Last call that's also a perfectly valid time all right by.

C

The way I just remembered uh the reason for the key lease uh documentation update was that somebody asked like: why do we have a key lease thing and not like just generically for any kind of thing? And that's because this document didn't reference srp, which is what needs the key lease. So I added that so just for completion or completeness next slide.

C

um Okay, so advertising proxy update. This is actually um this document. um I think we're converging on where we need to be, but um it's this was a fairly substantial up, update and re-reorg.

C

I I don't actually remember the details of how it was before, but basically I divided the document into talking about the different functions that the advertising proxy needs to. Do. I also updated the introduction and the the uh the abstract, but but this is the main updates were about how it functions, and it's kind of interesting, like the taxonomy that I came up with actually isn't talking just about the advertising proxy.

C

It's talking about all the things that need to be present in a thing that acts as an advertising proxy that's also doing srp um and uh because you could be doing srp to just a regular, authoritative, dns server, it doesn't have to be an advertising proxy and so that actually wound up like it's still basically talking about the advertising proxy, but there's a bunch of stuff in there. That's you know, you could argue, isn't an advertising proxy like, like uh you know, there's uh the srp registrar function.

C

Basically is an authoritative dns server when you're doing an advertising proxy in a stub networks context it might be bi-directional and you might have different things on one side than on the other, and so uh you know on the stub network side, you might need a discovery proxy serving information about the uh infrastructure network side. For those of you that don't know about stub networks, that's what the snack buff was about earlier and um since we're, I don't think we're going to go to working group last call on this.

C

I'm not going to go into detail on that. But if you want more details about that, you can ping me on the mailing list and I suspect, we'll wind up discussing this on the mailing list. um So.

A

Discovery, might I suggest if you want more detail, read the draft that.

C

Too but and you know and tell us and if there's.

A

Anything unclear ask on the list, because ted will answer the questions and also clara improve the document. So I think that's a great way to make sure we publish good documents, yeah.

C

Yeah, I mean absolutely, you know we we have to. We have to uh people, do need to read this document to see what you know to find bugs in it, um but I can help point you in the direction of other documents you should read, although actually, if you don't see the pointer in the in the draft, then maybe it needs to be there so um anyway. The other thing is uh if it's acting as a discovery proxy and it's acting as an authoritative server for the stub network.

C

It may also need to be a full service resolver for the stub network. So then the question is like: have we just stopped talking about the advertising proxy and really we need a separate draft for this or or does it make sense actually to talk about all these functions in this draft? So that's a question. The working group needs to answer. um I kind of think it makes sense to talk about the whole system in one draft, but you know that's my opinion, so I don't want to. I don't want to assume that I'm correct.

C

That's just how it looks to me. um So that's that's! The basic uh status- um and you know I think the document is fairly mature, but but, as we discussed earlier, it probably needs a bit more work and definitely needs more reading.

A

Thanks, um could we have some volunteers either in the room or remote to say, they'll read the draft and send comments. Your comments could also be just looks great to me, but we'd love to get more folks to to read it. Anyone like to volunteer to read this document.

A

Thank you, jonathan um hui stewart. If you could put that in the minutes, anyone else, let me check the chat joey, oh joey as well. Thanks awesome! No thank you. That's very helpful uh and I see our ad in the queue.

D

Yeah uh eric link, quick question and quick suggestions. I like the idea to keep the discovery proxy and the full service resolver in the same document, but I would suggest to change the title. Yeah.

C

Then I think that's coming if we have to if we do that, yeah, okay.

D

Okay, perfect yeah and then my intention was to bundle those three documents in the same cluster before the isg evaluation, so to keep them together because it's way easier to progress all together.

D

If it's delaying everything six months or one year, then this may be not a good idea. So at some point of time I think the author of the working group and the chair, we need to understand how to proceed those three together because it's way easier for the rest or separately yep.

C

That makes sense, I I think it absolutely makes sense to progress them together. If we can. um Hopefully we don't need to make too many more changes. We did a pretty. I mean I tried to do a pretty thorough update, but obviously one person writing an update doesn't mean that everybody's gonna understand what I wrote or agree that it's the right thing so hopefully that won't take too long.

A

Awesome: okay, that sounds like a good plan and we'll see, based on the uh how the review looks if we think we're in a place to move them forward. Yep.

B

A

Too long after the other ones,.

C

Okay, next slide: okay, so um srp replication. This is not a working group document, I'm just telling you guys about it, because I think it should be a working group document. We now have two uh implementations. uh The open thread has an implementation. Apple has an implementation.

C

uh We have not done any drop testing and I know for a fact that the implementations are currently not interoperable.

C

That's because the the open thread implementation did a bunch of new stuff that the apple implementation has not yet tracked. So there was an update to how replication servers discover each other. um This has been I. This is by the way, there's been a criticism of like this being the ted show. I just want to be clear that the all of the updates to the latest document were actually from upton and jonathan, so uh so upton and jonathan are both at google and both work on open thread.

C

um So um this document, um I think, is actually fairly mature. It's a fairly complicated thing that it's doing. um I think it's a really interesting thing that it's doing, um and hopefully there's.

B

C

General general interest in it um I'd like to see the working group adopted it. You know, I think it's ready to adopt at this point whether the working group is ready to adopt. It is another question, but but it's it's in pretty good shape.

A

Yeah, I think we're pretty close our thing. We discussed this among the chairs and what we were thinking is the two documents that we're going to start. The working group last call for as soon as those like the working coupe last call is successful and we send them to the iesg.

A

Then we'll start the adoption uh that way, we keep the amount of work in the hub, not too high.

A

But uh on that note, if anyone has concerns on this document and would think that adoption would not be the right play a thing to do, um you have some time here to come and and say why, uh because we'd love to hear that, of course, there'll be a formal adoption call, maybe in a few weeks on the list where people can also phrase concerns, but just wanted to make use of urban person time in case someone has concerns.

C

Okay, thanks uh not seeing anybody come up next slide. Okay, so I can't remember if I presented this at the last meeting, um this was definitely I think we did um so.

C

This is a document that um talks about a kind of an edge case that becomes a problem when you have more than one advertising proxy acting as an srp server, and they are for some reason not in sync, and there are a couple reasons why they might not be in sync, the normal behavior of an mdns responder that has that has authority for a particular name. Is that it's going to go out and try and see if there's any other mdns responder out there?

C

That has authority for that name using a probe and if it discovers, if it gets a reply back with an answer with data in it that conflicts with the data that it has, then it's going to tell whoever told it to advertise that data. You know it could be a server. It could just be a program, that's doing that, but in either case.

C

Basically, it's going to report back a name conflict, and so the idea is first come. First, serve whoever advertises in mdns a particular name. First gets it, somebody else comes along, tries to advertise the same name, they lose, um and that makes total sense when you've got like a printer coming onto your network, and it's got a particular name and you want it to always be advertising that name. You don't want some other printer to come along and get the same name and confuse you.

C

However, we've been doing some fun new stuff in in the dns ssd working group over the last few years, and one of the things we've been doing is srp and advertising proxies and an advertising proxy. Basically so srp updates a dns, authoritative zone notionally at least and an advertising proxy reflects the contents of that zone to a particular network link or links using mdns.

C

The problem with that is, if you've got two advertising proxies, both of which can in principle, receive srp updates from the same srp.

C

uh What's the word requester, thank you. It's a new terminology to me. um So so, if you, um if you, if you have, um if you have two srp one srp client, two srp servers, there are situations where an srp requester might have registered with a particular srp registrar and then it's unable to re-register with that registrar when some information changes prior to the lease on that information on the original server expiring. So we use the lease on the server to expire, stale data, but sometimes the data needs to be refreshed before it's stale.

C

In fact, frequently when there's an event like a you know, in a thread network, for example, we use srp and thread networks are our self-organizing mesh networks and you can have some kind of thing like somebody closes the door and suddenly the mesh can no longer see like it's been divided into two meshes and each one of them has a different srp server. Now you have a client that might have registered with the srp server. That's on the other mesh that it's not on.

C

So it's going to re-register with the srp server srp registrar, that's on the mesh that it's on and that srp registrar is going to get new data and we want the new data to win. So remember this: is we with mdns? We have first come first served, so that means that the old data is going to win, which is exactly what we don't want in this particular case, and so the time since received spec is basically defining a new eds zero option or actually it's a new uh sorry, it's a new dns rr type.

C

That's mdns specific! It's not really intended for use with dns, um but this new rr type um allows us to say when, in seconds in the past, we received the registration for the particular information that we're advertising over mdns in our mdns probe, and so if another server is also doing tsr, then it's going to get the it's going to get the probe.

C

It's going to look at its time since registration like when it received the registration and notice that its registration is older and because the tsr is there, it knows that we're not doing first come first serve we're doing, freshest data wins, and so it's going to relinquish its hold on its old data and now the uh the new registration is going to is going to take over. So that's kind of the primary motivation.

C

There are also some other edge cases with srp replication, where you can have a momentary conflict that you'd rather come out with the new registration. Winning their srp replication will ultimately clean things up, but you you'd rather not have to deal with that. So uh so this is. This is a document that I think is pretty important for the uh for the srp plus advertising proxy situation um and I'd like to see the working group adopted. It's pretty simple.

C

um That said, when we did our initial implementation, we got it completely wrong, and so fortunately stewart sorted us out and we managed to get it to work. So so that's why the document's been updated. So.

A

Thanks so similar to the other document, we'll be waiting a little bit until we get the other ones out the door uh and then what would be really nice if um we got um uh so we haven't you, I see you have a co-author from apple, which is.

D

A

And it would be great if you had someone, maybe interested in another implementation as well. uh You know we're talking to on minimizing it being the ted show. um So maybe you know we don't have time. We don't have to make an absolute determination, but if you can try to find someone else as well who's willing to help who's, maybe from a different affiliation, I think that would probably make the document stronger, um but otherwise yeah. If anyone thinks this is interesting and wants to learn about how writing rfcs is.

A

This is a great opportunity for you and you don't have to be an expert to write. An rfc like none of us were when we were right, wrote our first one right.

C

Yeah and also you have experts on hand, so you can get advice from them um and you don't also you also don't necessarily even have to be an expert on the protocol. The main thing is like you know, people make comments, somebody's got to update the document and you might have a discussion with the authors, who are experts on the protocol to figure out whether what the person says is sensible and how to address it. But it doesn't have to be that, like the person updating, the document is like a super protocol.

C

Expert who's done an implementation.

A

Yeah, so if you're interested reach out either, you know in person after the session or by email to to the current authors or to the chairs, whatever you prefer.

C

Okay, so that's all of the document updates.

A

If anyone has any questions about this documents or comments, this is also the time otherwise we're going to switch to the next set of slides.

A

C

So, by the way that document uh about uh discovering dns servers um is.

A

Actually, the one that expired, the one that expired.

C

Is actually germaine to the next discussion.

A

Oh perfect, yeah.

B

C

So these slides are basically here uh for the purposes of discussion or just presenting the problem, depending on what happens if nobody's interested in discussing this, then nobody's going to come up to the mic and I'm just going to breeze right through these slides and I'll explain them in some detail, and hopefully that will be useful to people who are listening and you'll, get some ideas and come back on the mailing list, but definitely like.

C

If you have uh something to contribute- or you know some questions or whatever in the middle of this presentation, don't wait until the end of the presentation come right up. It doesn't matter if we get through to the end of this presentation or not we're just the whole point of having this presentation is to have a discussion about making unit unicast d and ssd real.

C

So let's go to the first slide, so uh state of the art we already have a manual unicast dnssd. You can update his own file and if you do like, if the the ietf has has his own file and if you do a dig, then you'll get back. You know this. I I'm assuming you know a little bit of dnssd terminology.

C

So if you dig for an iprinter at meeting.ifidtf.org, you get back a couple of pointer records and if you dig down into those you get the srv records, you get the text records and so forth and you'll be able to print. um So so, if you have like you know pretty much any commercial operating system and also linux, it will be able to discover these printers and print on them. Cups will find these automatically if you have cups installed and then also we have.

G

Sorry, stuart from apple, um probably most of the people in the room know this, but I just want to check it because there might be some who don't um the reason ted is showing. This is not because we expect anybody to be typing dig commands right if you're on your iphone and you press the share button on a web page and go to print, you will see that ietf114 printer shows up in this available printer right.

B

G

That's because your iphone is doing this query to ask this network: are there any printers I can use? So that's, uh maybe that's obvious to everybody, but I just wanted to make sure.

C

Yeah the reason I put the guts up on the slide is actually because I there could be some dns people who don't know dnssd that well, and I want to just give them a little view of the of the guts of the protocol. But yeah that's absolutely right. This is this is all done automatically. You never want to actually have to type this stuff in so uh anyway.

C

Moving on to the second piece of state of the art- and this is something that, if you, uh if you buy like a uh an apple, uh homepod mini or apple tv- and I suspect there are other devices that do this, but I don't know the details um like this is this was me actually doing a dig at my apple tv, using mdns, to discover the apple tv and then look up in default.service.arpa, which is a domain that we happen to support for doing this kind of lookup uh any printers, and it did an mdns query and it responded with a record with a ttl of 10 that pointed to my brother, laser printer at home.

C

So that was all done automatically. That's that exists. You can buy things that do that. We have an rc that describes that it's really cool um and then uh we also have srp updating a dns, authoritative server.

C

Again, uh you know like if you have any sort of thread, border router, including an apple tv or a mac, mini the latest ones. um They support srp updates and they support the advertising proxy. Of course, the advertising proxy isn't really unicast, but I mention it because srp is um just to give you an idea of what what building blocks we have already built. What we already have available to use- um and uh this is all this- is all in open source code. So it's not like it's just an apple proprietary thing.

C

I think that open thread has implementations of most of most or all of this stuff. Yeah jonathan knows everything about open thread. So next slide.

G

Do you mind me jumping up and in um let's go back to that slide because um I think ted sort of glossed over? Like I mind, a miracle happened, and um you know it might be. You know it's the kind of thing that would be good to explain with the picture so, where ted shows that dig command office.local under discovery proxy, um I would just want to say a couple of sentences about more.

G

What's going on there traditionally today on most of our home networks, devices using multicast dns are multicasting the whole network, and we know that multicast on wi-fi is slow and unreliable and wasteful of spectrum, and when you had two or three devices on a typical home network that wasn't a big deal now, if I had up all my home kit devices and the garden sprinkler controller and the solar panel inverters there's more than 100 wi-fi devices on my network and when my iphone is looking for printers it multicasts every device saying.

G

Are you a printer and.

E

G

Switches like no I'm still a light, switch stop asking.

A

G

So so what ted did with that command was instead of multicasting the whole network he sent a unicast to, in this case his homepod and said: look you probably have a cache. That's up to date. Could you just tell me if there any printers, without bothering everybody and um if, if the homepod doesn't know it's going to multicast on your behalf?

G

But if somebody else asked the same question two seconds ago, you don't have to spam the whole network with another multicast, the homepod can just say, yeah, here's the answers, and so this is the first step in the direction of trying to make a lot less use of multicast on our home networks and move more of it to unicast.

C

Yeah I'll say two things that stuart was polite enough, not to say one is ted. You forgot the motivating slide, which I.

B

C

Sorry um and two is um mdns- is actually really smart, like it's insanely, smart, it does all this cool stuff to avoid multicasting if it doesn't have to, and so um every mdns responder that you have sitting on your network and every apple device.

C

You have every android phone, you have every windows machine you have is doing this all the time they sit there and they listen for mdns, packets and they're, just passively snooping on the network, all the time and they're building a little cache that contains all the information about all the services that they've seen advertised on the network.

C

If anybody ever asks whether there's a service present, all the other devices that are on the network get that multicast and add the service to their cache. This by the way, explains why mdns is sometimes flaky. If you have a network that filters out uh multicast packets, then the cache building algorithm uh may make a mistake, because you know somebody sent out a query.

C

It didn't see any responses, and so it assumes there aren't any assumes that it also wouldn't get an answer if it sends out a query, um and so you know, if you have something that's suppressing multicast, then you can wind up with an incomplete cache and uh negative responses when you should have gotten positive responses.

C

So um the discovery proxy is actually a really useful piece of technology because it takes out all of these mdns responders sitting around doing anybody can talk to a discovery proxy and get the same exact behavior as if they were talking to as if they were doing mdns themselves, except that they're not doing all of that multicast snooping and they're, not doing all that multicast uh broadcasting they're. Just you know they just send a unicast to the discovery proxy and the discovery proxy takes care of it for them.

C

So um so the motivation with unicast bonjour is um in a sense to get rid of of multicast on every link, um or at least every link where we care about getting rid of multicast. And that means every wi-fi link, because wi-fi is not great with multicast.

C

If you have a a wi-fi mesh, it's hard to get multicast to work well on a wi-fi mesh for you know, complicated, but probably fairly obvious reasons um and so being able to to do unicast instead of multicast in the same context and get the same results is a pretty clear win, and so the question is: can we do it, and so the point of this slide is to talk about what pieces we've already done. Let's now go on to the next slide, so what would it take?

C

um We need to be able to find the unicast dns ssd service right. So thinking about the previous slide, I just happen to know that office.local has a unicast dns ssd service. So I did a dig pointed at that, and I got my answer. How did I know that? Because I just happened to know that all apple tvs have that- and I happen to know that that was the name of my apple tv, and so I could type it in. Obviously, that's not going to do it. That's not automatic.

C

What's that yeah yeah and I wrote it.

A

Sorry step one for using this get a job at apple, yeah,.

C

I I know so much more about dnssd than I did before. I started at apple, it's very exciting, um so um so we need to be able to discover the dns ssd service. We also need to be able remember we want to do unicast in both directions. Right. We don't want to just do unicast for discovering services, because that's not as good as doing unicast for also advertising services.

C

So um we need to be able to uh to discover the availability of an srp registrar on our local network, um and uh I don't know why I said as above: um oh discoverable. No, I don't. I still don't know why I said it about. I know I had a reason. I just don't remember what it was, um but so it's an authoritative, dns server um that is being maintained by srp.

C

um We we need a discovery proxy, because um stuart knows why I said as above.

G

uh I I think I know what you're trying to say um we have. This is like two sides of a coin: yeah we have clients that are looking for. Services want to discover a discovery proxy that can do that on their behalf and that eliminates one side of the multicast devices that want to offer services on the network want to be able to discover a registry that they can register with, and those sound like very similar things, and they are very similar things.

G

But one is a client looking for services and the other is services seeking to offer their services, make them visible to clients right.

C

G

That's what you meant by.

B

C

Yeah so, and um we need to uh let's see so yeah we need to, we need to bear in mind that there are going to be devices on the network that don't know how to do srp right. So, like you know, maybe I'm going to cram srp registration into some future version of some. You know operating system, but I can't assume that my brother printer is going to ever get a software update to do that. So I'm still going to need to be able to do mdns to discover my brother printer.

C

Hopefully future brother printers will fix this and maybe I'll get a firmware update, but I can't count on it. So we have to have a discovery proxy to to just get us the legacy clients the legacy services. I should say we need a full service resolver. um The reason we well so first full service resolver. What what it gives us is that when we get a query uh for stuff on the local link, the full service resolver, you know on port 53 or whatever the full service resolver knows.

C

Oh, I need to go into this database to get that information, not just forward it to my isp and the other thing is so we have all of these devices that are consuming this service, but what? If the service goes away, we may not need this. It depends on how we're doing the service if the service is provided by the network like by your home router. Well, when the home router goes away, okay, you're not going to be able to do mdns, but your home router went away.

C

You don't have wi-fi it's not going to matter that much when it comes back. You'll have it again, so we don't need to solve that problem, but suppose that, for example, we decide that that.

B

C

Home riders don't currently offer this functionality. uh Maybe we want to offer this functionality that you can discover through mdns right discover, you know the replacement for mdns using mdns, and then you can stop using mdns until it goes away. uh Well, okay, so if it goes away, then we need to fall back.

F

C

That's the point next slide.

C

So um and then another thing to think about- and this is actually a hard problem- um is how we address the various ways we could deploy this so a typical way to deploy. It would be that you've got a single link in your home network and you just need to be able to do what you're already doing right right now. You can already discover your printer on your home network. You only have one link um and uh you know we just want to replicate that same functionality.

C

um Another use case is where you have pretty much the same setup except you have some stub networks, like you, have some thread: border, routers or whatever that are connected to your home network and you'd like to be able to discover the services that are being advertised by hosts on the thread network, as well as the services that are being advertised on the wi-fi network.

C

um You might have a multi-link network, that's that's somewhat managed like a soho network or even an enterprise network, um and then so that's like what the network looks like and then there's the question of what the service offering looks like so so the service I'm talking about here is the unicast dnssd service, so that service might be part of the infrastructure. It could be something that comes on your home router. uh It could be something that doesn't come on your home router.

C

If it doesn't come on your home router, then maybe we want to offer it using mdns. As I said earlier, um it could also be managed by, like you know, an I.t staff right. So there are a lot of ways this could happen. So my point in putting up the slide is not to say what the deployment models are, but just to talk about the deployment model problem so that we think about that next slide and then there's like the naming model. So um you know the naming model for multicast.

C

Dns is really simple: everything ends in dot local right. You can advertise names that don't end in local and mdns. It's not forbidden and in fact I've used that functionality joey wrote some code that uses that functionality, so so it does work, but generally speaking, when you're doing service discovery uh with mdns you're using.local, so one naming model we could use is to just replicate that, like you know, if you say local, then we do unicast dnssd to do the resolution, for whatever is in dot local and dot.

C

Local just means the network link that I found this service on right. So you know you might have several network links um and each of those network links with multicast dns is its own little dot. Local.

C

Those network links can actually have conflicting information on them, which is a bit of a problem um and there's no way to resolve that because the links aren't connected to each other. So there are problems with using.local that way, but you can use local that way as long as you're willing to accept those failure modes.

C

So one nice thing about using.local is: if the, if your your dns, you know all singing all dancing, unicast dns, sd uh discovery service goes away, then you don't need to use a different name when you're using mdns. So there's an advantage there again, I'm not saying what we should do, I'm just describing some of the issues and some of the ways we could think about this.

C

So another approach which we actually have been talking about more when we were doing the home net stuff. We talked about this and I think the discovery broker document that stewart did a while ago, which has expired, talks about this and also the document that expired, that we were talking about earlier talks about this, and that is just give every link a a global name. So every link has a name that is that is unique to that link and whenever you want to discover services on that link, you use that name.

C

And so uh you know, mdns dnssd has this concept of a legacy browsing domain and that's a list of a legacy browsing domain list and that's a list of domains that you sort of by default. You know in your legacy, behavior, which we never actually figured out what the non-legacy behavior was so legacy. Behavior is the current behavior. um You just do service discovery.

C

If you get a if you got a question like give me the list of all printers um and it doesn't specify a domain, then the legacy browsing domain is what you use to iterate across the set of domains on which you're going to do that service discovery. So so we could do that and we could. The legacy browsing domain on any given link could be um a list of all of the the per-link names uh that are present in the local infrastructure. Right. That's one way to solve this. um These aren't necessarily mutually exclusive.

C

Either right you could. You could say you know whenever you do a local query. That means the link that you're attached to, but you're also allowed to do um you know you could do the same query by specifying the link, the global name for that link, and you would get the same list of answers. So that's another approach. So again, I'm not prescribing anything. I'm just saying like here are the naming models that we've we've been talking about and we need to figure out.

C

If we're going to do unicast dnssd, we need to figure out how we're going to approach this. We may come up with an approach that says you know. In the most simple case, we do local, but we need to have this per link naming thing in our back pocket for the more complicated cases or we may say you know we really should do prolink naming because gosh that really solves the the name. Conflict problem nicely right so anyway. Those are those are some topics.

C

Next slide, I don't know if we run out obstacles, yeah, so um yeah. One issue, I was talking about legacy browsing domains. One issue is the legacy. Browsing domain only works currently at least on apple platforms. I don't know if this is true of other platforms.

C

If you don't specify a domain to to do service discovery in all right, you just you pass null in for the domain and then it gives it uses the legacy browsing domain list as the list of domains to do queries in a lot of people pass.local, and so do we need to override that um we have to kind of answer that question uh when we're thinking about the domain uh naming or the the link naming problem. um So um you know, if you do, there are advantages to doing perlink naming as opposed to using.local.

C

If you do perlink naming, then the name of the device doesn't change depending on where you are. um If you don't do perlink naming or if you do perlink naming and do.local, then if a device was discovered using local, then it also has this other name which you could potent you could potentially use to talk to the device but you're not going to, because you know the device by its local name, which is not valid everywhere. Is that a problem? I don't know if that's a problem.

C

That is just a thing to think about, so we have a question.

F

Thanks steve, my name is subidas. I just want to ask you a basic question when you say link right, is it a and also you have a example of wi-fi right? So is it the link means an ip link or is it a wi-fi layer link like a layer, tooling.

C

Yeah, so I'm using wi-fi as a shorthand. That's a good question, I'm using wi-fi as a shorthand for the infrastructure link which might be a link, that's bridged between ethernet and wi-fi, or might be wi-fi only or ethernet only it doesn't really matter. I just used wi-fi as sort of because wi-fi is the usual right.

F

Right, yeah also, the reason I'm asking is that possibly even stuart know that in wi-fi new evolution happening with multi-link device right so today, if I have a one radio in one link, that means I have a full stack to the ip on that particular link even in so what is coming in future is that multiple links, layer two will represent that one interface to the ip. So that means I can have two links right with my device and I'm operating, but I'm connecting with one ip link to the router to the back end right.

F

So I can then, if I send a query right, I can actually send only one link, not the all links right. So I'm just trying to understand that scenario that when the query goes, will that query go to every wi-fi link or the query only go. uh You know only one link to the network right. I.

C

Think stuart has an answer for that I'll just say for my own opinion that that that's a question we need to answer.

G

uh What I was actually going to say is: um I'm not actually aware of what you're talking about with these new developments in wi-fi. So thank you for coming up to the microphone to make us aware of that and we're kind of out of time now. But we should definitely talk more and learn about that.

F

Yes, yes, so yeah just to give you know, since I'm also involved there. So next generation wi-fi, which is wi-fi seven, which will come in 24 right, that's the market uh we are looking at. I think what is happening in ieee is that a a device can have multiple links both for the endpoints and that ap, and then it will only uh open up one interface to the ip and they don't hide the multiple lower links.

C

It's it's interesting because the use case that I actually care about is the exact opposite of the one you just described. I want to be able to connect to multiple ssids using a single radio right.

F

So one thing one thing also: we all know that you know in in ieee terms they don't talk about ssid right, that's the deployment model right, so that is, of course, something will evolve and how those are configured right. But the way that things are evolving is that there is no visibility for the ip that the underlying the multiple links are, and also it is allowed that device can have one at a time say two or three links, but it can decide or operate only one link.

F

You know at a given time, but it can have at least two links and that's where it is evolving.

C

Well, I certainly look forward to seeing this stuff when it when it's available to look at that.

F

Sounds very cool, wait for wi-fi seven yeah thank.

C

You cool thanks.

A

Sabir yeah dave and I think we're gonna cut the queue after dave because we're almost yeah.

E

I'm doing this because I just figured you were about to do that, I'm to take advantage of having been a note taker to continue sue beer's uh theme of expanding use cases um mdns is starting. It adopted in the parallel universe, called storage. uh The end nvme over fabrics is the successor to iscsi as a network storage. Protocol. Nvme of is not an ietf protocol, but it's using mdns to solve the discovery problem.

E

It's going to be doing it in exactly enterprise networks and the big ones where you don't dare let the multicast domain scale over over even a small portion of the network, and so it's headed right for the for the problems this group this working was taking up. This is another place to go looking for people who might be very interested in implementation.

C

Can you uh you, you actually know those people, it sounds like.

E

um I got to be careful because one of the one of the things that gets in my way here is that nvme uh protocol development work is done under an nda. So I have to have discussions like that with someone, who's asked who's comp who, whose company is under the same nda, and I apologize for that difficulty.

C

Totally understand um the reason I mentioned it is because it might be possible for you to tell them to talk to me so that they don't have to tell me anything about nvme. They just need to tell me about what they need from me.

E

um We'll have to we'll have to look at the details here. Unfortunately, storage is different enough from a printer that you will need to understand why the problem is different.

C

Okay, well, we might also be under the nda. I don't know anyway. uh Let's see did we cover everything, yeah, okay, uh yeah. I think we pretty much cover so so. Basically, you guys now understand the problem.

A

All right, well thanks, so much for all the presentations ted thanks so much for everyone who participated. That was some interesting information that we didn't know. That's really helpful and thanks to our note, notetakers jordan dave and I guess to our jaguar scribe me: you're, welcome uh and thanks everyone for coming uh happy rest of your itf week, and we will see you on the mailing list. I hope we'd love to get as much review of the documents as possible.

A

A