Session Date/Time: 19 Mar 2026 01:00
Toerless Eckert: Good morning, everybody. It's Thursday of IETF 119. I hope you found that as great so far as I did. We're nearing the end, but now two hours full-packed agenda for ANIMA, so let's get started.
Note Well. You have actually signed that you have read and understood and are going to comply with the Note Well when you registered for the IETF, so we don't need to linger here on it, but please make sure, behave professionally and follow all the other rules on it.
Please, if you're in the room, log into the Meetecho anyhow, because otherwise we'll get a very, very tiny small room next time, whichever tool you choose, full or on-site tool. Also, please contribute to the meeting notes. The agenda is the same page as the meeting notes, so that's very easy. You want to go to the agenda anyhow to see what's coming up while we're in the meeting.
Quick update on the status of the ANIMA documents and what we're going to talk about here. So we've got unchanged an RFC Editor cluster C484 with the JWS Voucher, BRSKI Cloud, and a non-ANIMA document that also depends on RFC 8366bis. So this cluster is going to be released once we finish 8366bis, which we're going to talk about today. Also, BRSKI-PRM has a dependency against 8366bis, so nothing changed here on this slide.
8366bis, lots of work. We're going to talk about it today. The constrained BRSKI solution with voucher and proxy, we're also going to talk about it, so this has gotten more attention now after we've been winding down the work on 8366bis between the participants. BRSKI Discovery, I'm going to give an update. Constrained GRASP, there's also going to be an update.
We have a parked document. Nothing changed on that, but the network service auto-deployment has been worked on after also being on hiatus for a long time, so that's great. And then, time permitting obviously, we're going to look into a couple of new work proposals, which I'm not going to read out in detail. So let's make sure that we still do some good time tracking and with that, I think we can move over to the first slot, which is constrained BRSKI. So, Esko, up to you. Do you want to have the slides yourself or...?
Esko Dijk: Yeah, maybe first check the audio if this works.
Toerless Eckert: Yep.
Esko Dijk: And then, yeah, I can maybe request slides and see myself if that works. Toerless has to stop sharing first.
Toerless Eckert: Yeah, yeah, already happened. And now, where is... Esko, okay. Yes, slide control. And I think... yeah. No, before you pass on the slide, let's just reload. Oh, okay, yeah. I'm not helping here. Okay, there's the deck. There we go. Okay, I think I have control now.
So I wanted to introduce these two drafts here. So draft-ietf-anima-constrained-voucher is the first one. Let's see if this works, moving to slide two now.
So here's a very quick recap slide which I wanted to skip in the presentation. It's more for reference for those people who might not have seen this yet. So we are talking about a constrained version of BRSKI here that's suitable for Internet of Things type of networks, for example, a 6LoWPAN mesh network.
What are the updates since last time? Well, there is a bit of new functionality defined here. So, two changes here on the slide. So the first one is basically the introduction of the new URI-path abrf option. So this is an option basically being defined now in the CORE working group, a new option to make it possible to send a CoAP request to a very short path using this new option. And the idea is to require this for the registrar so that in case a client wants to use it for the cBRSKI bootstrapping, it can use that.
Yeah, the second update is that the registrar now also sends more data to the MASA. So, there's text saying that it basically adds the entire pledge's certificate chain. And this, well, is sometimes helpful for the MASA because you could have a minimal MASA that does not store IDevIDs for all pledges, but just stores, for example, the CA certificates for those specific pledges. And then with the certificate chain, the MASA can still check that the request is valid and is able to build the chain itself. And it's also useful for diagnostics at the MASA side, for example, in failure cases or attack cases. So this is a relatively simple change that we have discussed prior to the meeting.
Okay, then I'll move to the next slide with more updates here. So there's also some content removed here. So it's actually the IDevID issuer considerations that we had are now moved to 8366bis. And the reason is that these considerations are applicable to all BRSKI variants and basically also to the base idea of the voucher and it's not just for cBRSKI. So we decided to move that, and that's now done with updates to both drafts. And of course some editorial, yeah, changes and fixes here.
Then I'll move to the next slide that basically explains the remaining open issues. So there's one issue recently added. This is something we should consider whether it is required here, to add basically details for the supported cipher suites for DTLS. So there's a GitHub issue for that. So we found during the work on this, or at least Michael remarked that, "Hey, we don't have any details on that, only basically the version that's to be used."
And the current draft basically has some version requirements that are listed on the slide. So it's basically DTLS 1.3 is recommended and there is one clear exception case where clients still can use DTLS 1.2, and the registrar must implement both, support for both. And it can also optionally be configured to accept DTLS 1.3 only. But we don't say anything about the cipher suites, basically no details there.
So we do have in the examples a particular, yeah, combination of basically crypto parameters, as shown on the slide here. And the question is of course here, do we need such details for DTLS? So that's the open question here. And if there are any particular views on that here, I think it would be good to add that. We can also discuss here if there's time. First I'll just jump to the final part of the presentation, so the next steps. Well, resolve the open issue then is a next step and wait for the dependency 8366bis to complete.
Toerless Eckert: Can I maybe inject a quick comment? I think the cipher suite details will be asked for. I spent a long time in 8994 ACP with the security AD review, so I think we can shortcut this now by doing an early review with the Security Directorate at a point in time when we feel we should do it and that the rest is fine.
Esko Dijk: Yeah, so would you like to first do the review or first add some details to the draft?
Toerless Eckert: No, I think I'd first like to do shepherd review and then go from there.
Esko Dijk: Okay, yes. That seems good.
Yeah, then the next draft is draft-ietf-anima-constrained-join-proxy, which is very much related of course. So this shows basically the same picture but now highlights the role of the join proxy. It's basically the device that has already joined the network and can help another device in the mesh to join, in this case, the pledge.
So, this is to highlight the updates which are none since IETF 124, and the reason is that we do have some final open issues there, but so far they did not yet lead to a decision to change anything. Two issues are related to CORE Link Format and this is something I wanted to basically take to the next CORE working group interim just to do a quick check if those ideas there are feasible and then if needed, adapt the draft then.
So what are these open issues that are also to be taken to the CORE working group? Well, the first one I have already put my verdict on in GitHub. So the question is basically, in the join proxy, do we need to support this new option, URI-path abbreviation, that I discussed previously? While it's very useful to support it in the registrar, my conclusion here is that it is not worth mandating this option on constrained IoT devices, so for the join proxies. And there's some detailed reasons also stated in the GitHub issue there. So overall, it's just that the basically the size reduction for this operation is very, yeah, for introducing this option, the size reduction is very small for the discovery messages. So it doesn't really help much here. And the messages are not that big anyway, so these are unsecured CoAP discovery messages and responses to that.
Yeah, the other open issues are related to simplifying the CORE Link Format that's used for discovery of the join proxy. And in the current solution there is basically a link format document being sent by the join proxy that includes basically a long IPv6 address in ASCII that is also unused in the link format payload. So that's why I wanted to find an alternative that is a bit easier and simpler and has some benefits, so reduces the payload size and there's no need for the join proxy to generate the IPv6 address string just to be compliant to the specification while this string is not really used by the client who receives it.
So this is something I wanted to further discuss. So these are also the next steps of course, take this CORE 11 ideas to the CORE working group interims, which will start again I think in April somewhere. And then also wait for the dependency to complete. So this is the end of the presentation, so it covers these both drafts. Yeah, if there are any questions, let me know. Otherwise, we can move on.
Toerless Eckert: Yeah, yeah, thank you very much. And would like to invite everybody here to consider reviewing the documents, commenting on them. These are still not fully through, so very good opportunity to do that type of review. And otherwise, I'll be doing the shepherd reviews and then we'll look for early directorate reviews before moving on to the AD review. Okay, thank you.
Esko Dijk: Okay, thank you.
Toerless Eckert: Next, draft-ietf-anima-rfc8366bis. So let's go. We're going to share slides again. What... who has the share now? I just clicked on... Oh, okay, so let's take yes. Slide control. I have... RFC 8366bis configuration. And then, bis bis.
Michael Richardson: So, and thank you very much. Hi, I'm Michael Richardson, I'll be talking and updating on the status of 8366bis. Um, so we adopted this document some time ago, and I think we're almost completely done here.
So, working group last call ended at the end of January, and in that process we added Esko as a co-author and we removed Max Pritikin, with his blessing. He has not been able to be involved in the IETF for some years now. Our AD Mahesh did his review in February and most of those comments were processed last week with version 08 posted on the Sunday. There's a 09 that was just posted. There was one change to the YANG that did not get through for tooling issues, so you'll see that, and that relates actually to what Esko was talking about with the DTLS things where there were some comments in the YANG about BCP 14 in the YANG, which just was not a good place to put it.
It now correctly updates RFC 8995 and obsoletes 8366. That's clearer. All the references that were aliased from 8995 to BRSKI were changed back to 8995. And that's because there are some comments and some things that refer to 8995 in the text where it's not again another reference just because it's been said several times in that sentence. So this just removes confusion, especially among readers and reviewers that don't know those are the same thing.
The list of YANG authors is now the same as the list for the document. The YANG was being 8792 wrapped, which was not necessary. The YANG is wrapped already, but it did confuse the Datatracker, so that's been removed. And then I mentioned that this BCP 14 statement in the YANG were removed and Esko, I think, has successfully put them into the cBRSKI document. And we were advised to remove the word "grouping" from the names of the YANG groupings because that was redundant. I was worried that that was going to break something, but it did not, and I do not think we have any external references to our YANG anymore, so that's not a... it would be a backward compatible problem if that was, but it's not. I don't think that's a problem anymore.
So that's it. It's, I think, it's in Mahesh's hands again to go up to the IESG, and I guess that'll get a date sometime in April for the teleconference. The following is the list of six documents that are either in the RFC Editor queue or are waiting to get through that depend on this document. And so, pretty important that we get it done finally. So that's good, and that's about it. The last slide is backup. Any questions?
Toerless Eckert: Yeah, just a quick note that, well, I've got this one review comment. Mhm.
Michael Richardson: Right.
Toerless Eckert: Not a question, just here to say thank you. Yes, it was... it's a major document just blocking too many other documents that were all sitting on my queue. And I'm happy to review it after this IETF meeting. I'm off next week, but the week after, I do promise to take a look at it and send it off to IESG for review. Thank you.
Michael Richardson: So you're not taking the document with you on vacation?
Toerless Eckert: No. No. Okay, alright. Brian.
Brian Carpenter: Yeah, hi. Um, I just wanted to say this is a "no comment" comment. I think it applies to Esko as well. These are pretty specialized documents, so if people who consider themselves part of the general public, such as me, don't comment, it's not because we don't care, it's because we think only experts can realistically comment on these documents. But, you know, I'm sort of very glad this work is being done and I wish I understood it better, but I don't. And I think there's probably quite a lot of people in that situation. So thank you.
Michael Richardson: Um, maybe if it's useful, you know, I did some screencasts at one point. I don't know that they require... I don't know that this document requires changing them, but um, if there's something about making them more accessible, um, that... I'm totally into that. But um, I can only answer questions that people have, so... pose them.
Brian Carpenter: Yeah, fair enough.
Toerless Eckert: Alright, let's go on to the next one, which is the operational considerations. Let me see. Do I push this? I can stop the slides. Okay, and then you can push them. You have to approve the slides anyway. There you go. Yeah, oh, I get "share." I can do that. Oh, okay, confirm my selection. Apparently. Alright, I guess I did it. Alright.
Michael Richardson: So, we had two documents. We've discussed this a couple times, but finally I put some slides together around this. This is the operational considerations for the Registrar and the MASA (draft-ietf-anima-masa-considerations and draft-ietf-anima-registrar-considerations). Thomas Werner has said he wants to be involved. I'm not sure if he's... if he got up at the right time because he didn't travel, I know. But um, so he's going to be co-authoring that, I believe, and we have to figure out what we're going to do. Thomas is the author of another, you know, triple of MASA Registrar client code. So, and if there's any other implementers that want to contribute, of course we would welcome that.
So, how did this start? Um, so a lot of these things, I started this document in 2019, early 2019, as we were implementing and we're going through BRSKI and there was a bunch of things that I said, "Okay, well this is not an interoperability concern, but maybe it needs to be written down somewhere." And I started just throwing them into two documents and they grew and changed and a bunch of text moved from some of these documents to a T2TRG document which I hope will get published any hour now. But um, yeah.
So then the question, as we adopted these in a couple of years ago, was should... do we need two documents or one document and what are commonalities between them and what things could be said that are different. So this is what the table of contents for the registrar operations... operational considerations is. And some of these things are, you know, in some ways almost extended security considerations, but they're more like, you know, why you... which private keys you might need to keep safe and what happens if you don't keep them safe or you need to recover from that. But also things like how what happens when you attempt to scale the registrar. And the obvious way is that you scale it horizontally as most web properties do by adding web servers, often in front of a... behind a load balancer.
Although because of the discovery mechanisms, you could actually omit that and just allow the pledge to pick a random host. But then we get into issues of the join proxy and other things that we've discussed. But if you do horizontally scale it, then the question becomes: where are the private keys? Are they the same? Are they different? Where do the signatures occur? And which keys do you pin if you have more than one? And some of those considerations actually came up early enough in 2020 and there were text changes to 8995 kind of at the last minute to make some of this, because some of these did have interoperability issues and so we did change some of those things. And there's some additional considerations I think in cBRSKI as well about how to pin things because there are new ways of pinning things that matter and you've got to get them right or it doesn't work.
So there are some diagrams and other stuff, this is the table of contents for that. And that was a little bit, yeah, I already said a lot of these things. So there's a little bit of, "Okay, you could do something as long as the implementation supports it," and that becomes a quality of implementation issue, until there are things that you can't... that another party can't do because they are trying to cope with a low quality of implementation.
And so this is... there's a little bit of back and forth here as to what to do. And honestly, it might be that this document in the end after we kind of collect more information... and I don't think we need to rush in any way for this document. We might decide that we've collected all the information we need and we don't need to publish it as an RFC. But for the moment, it's there. So for instance, as an example, this RFC 9440, which you can see is relatively recent, which is the Client-Cert HTTP Header field, and you are not going to be able to put your MASA or your registrar into something like an EC2 with a hardware offload of TLS if you can't get the client cert, because we need the client cert. In... at least the registrar does, and the MASA may also need it.
So you need that, and there was not until 9440 actually a standard way of doing that. It was specific to the load balancer that you're using if it supported it at all. And that's a... that's an operational deployment consideration that implementers need to be aware of, but that fundamentally does not change the protocol. It just potentially breaks the protocol if you gave it to someone that didn't understand that they needed to do that there.
So what else have we got? So the MASA operational table of contents, table of contents. And the majority of this has to do with what the PKIs you are maintaining, and how are you signing the IDevIDs, and how are you signing the vouchers, and how do those keys relate? And how do they... do they go up to a single trust anchor that the pledge is... knows about? Does it go up to multiple pledge trust anchors? Do you share those trust anchors across multiple products if you have multiple products with one MASA?
And there's all sorts of different ways of doing... of doing this. And they're all essentially manufacturer considerations that they need to make a decision as to what they're doing and then they probably need to stick with it over time. And if they decide to change their mind, then they have to deal with the forward and backward compatibility with their own products. And so that becomes their issue for that.
And then there's some concern about like business continuity, right? I mean, do you... what happens if your MASA private key is destroyed in a flood in your data center? What do you do then? Well, you have a problem. If... but you might have business continuity and you may have split the keys intelligently and this kind of stuff. And that's actually some of the Trust Anchor, T2TRG Trust Anchor document contains some more discussion about that and what amount of disclosure you're going to get and that kind of stuff.
So, yeah, so I just talked about that. So there is a bunch of PKI advice in both the MASA and Registrar document, and this kind of collects those two things. And those things could go together in a merged document. We could have a lot of back-and-forth conversation about how to... what are the options for doing this and how they apply to different kinds of things, and what are appropriate kinds of levels of technology or complexity that the registrar may want to do.
And the three examples that I gave was, you know, a Tier 1 ISP versus an enterprise network versus a home network. The level of complexity and the number of things they may have to fix if they... if they make a mistake, differs between them. So you have to think about what's going on for that. So those are the things that you could collect and quite might more reasonably be publishable as a BCP. But again, I think we need a lot of actual experience before that's specifically useful to publish.
Toerless Eckert: Mind a comment?
Michael Richardson: Yes, please.
Toerless Eckert: So with respect to merging or non-merging, right? So it seems as if the MASA considerations are very much manufacturer considerations. So they're addressing a different community than the registrar, which is kind of the owner. And maybe we just want to change the names, right? So one is kind of BRSKI owner considerations, which is mostly registrar, but other pieces as well, kind of, you know, "don't buy pledges from people who really don't do good BRSKI" or something. And then the other manufacturer considerations. So that would maybe be a good reason to keep them separate.
Michael Richardson: I agree.
Toerless Eckert: And further, the MASA considerations are not so much product mandatory to implement or nice to have implemented considerations but actually become operational, what you're doing. Whereas the registrar considerations are many ways... if you got a registrar and it didn't do these features, then you probably aren't going to be... it's probably the wrong choice for you.
Right. And the other part obviously my pet peeve is the use of sub-CAs as a mean to, you know, simplify manufacturing, right? Because you're typically contracting as a big manufacturer some manufacturing plants and they need to have their own sub-CA. So if something like that isn't in the text, then I'll be happy to try to figure out where to put it and see that we bring it in, because I think we've been going through the trouble of making sure BRSKI and now constrained BRSKI supports that. So I think that's a major help in supporting flexible deployment.
There is actually a fairly sophisticated operational market now, so busy they won't talk to people, of doing manufacturer factory-installed keys and multiple companies with multiple products that help people do it. And yeah, a whole... they seemingly can support all the different options here, it's just getting them to actually... they're so busy they're so busy working they can't they can't be bothered to market. Stefan.
Stefan: Hi, good morning. Yeah, maybe just as some side note regarding the merging of the documents because I think I proposed this or we discussed that in the design team. The reason for merging it basically from my understanding would be beneficial because the MASA operator and also the registrar operator, they would somehow interact, on one hand for doing some kind of trust or may do some kind of trust establishment before, but also on the other hand to during operation. And to have some more background on the operational side of either the registrar or the MASA may help to understand doing certain design decisions or doing certain operational decisions on either registrar or MASA side. So that was essentially the reason for proposing to merge both documents.
Michael Richardson: I agree with you, it would both give them the ability... it would give both operational personnel a common language by which to communicate, usually because something didn't go right and they say, "Oh, well, I am a per-product intertwined IDevID PKI," and the registrar person says, "Oh, you're a... oh, we don't know how to do that. Okay, well file a bug report with our supplier," right, or something, and they would know what it is that's... and I don't think it has an operational impact, but bugs are bugs, right?
Stefan: Okay, thanks.
Michael Richardson: So, there's scaling advice and about this, and there are considerations around which keys do you create, and as Toerless just mentioned about having subordinate CA keys, and that's one of the ways of doing horizontal scaling between like you could have a manufacturing plant that... or you could have manufacturing in multiple locations and so that's one of the ways is: don't share that private key because you do two subordinates.
Or you have the CA online, and you know, it's operational when the plant is operational and it's not otherwise, and there's things like that. There's a diagram in the Registrar document that I think is on the next slide that deals with some of the architectural things in the registrar doing horizontal scaling. And I think let me see if that's the right one. Yes, there we go.
So, you know, this is the thing, so one of the ways my implementation has is all as monolithic. All of these objects except the database really are all in the same process. And so when you do a... when the pledge does an enrollment, which is the bottom side of things, it waits while the system talks to the MASA. There could be a timeout, there's some mechanisms in 8995 to deal with that timeout, to retry and things like that.
But one of the other ways of doing this is that the pledge interface could receive that voucher request, could stick it in the database, and then wait for some other process to pick it up and do the MASA interaction and return a voucher to it. And it could always tell the waiting pledge that it's going to have to wait and come back. And I don't think my code actually supports that, my pledge code supports that. That's a bug. But there's different ways of doing that, and when you do those different things, you've got to decide, "Well, when the registrar signs its registrar voucher request, is that private key on the bottom? And so you put a signed thing into the database? Or is it on the top, in the top box, in which case you maybe have one of them across the different things?"
And there's different ways of doing this, and that's one of the things that comes into, you know, what are you pinning exactly? And you know, are you going to... if you horizontally scale the pledge interface, then you sign... do the signing down there? Are you going to create slightly ephemeral registrar keys here for signing it, but you're going to be make sure to pin something above it? So you have to figure that part out clearly and this does have an interoperability implication and I think we got it right already, but that's part of the process here.
In the Registrar document, we have this diagram that I created at the very beginning. And the intention of it was to talk about network and ACP partitioning and what happens to a network when you're trying to say bring on a new device but the network is broken, it's partitioned, and you might not be able to get to the registrar you thought you were going to get to to bring things back online. And maybe that was too ambitious for this document or too early and so if we... I would at this point rip this diagram and much of the related text out. But, you know, you can imagine that you had, I don't know, this Tokyo router, it's crashed, it's died, you have to replace it. And but because it's down, your network is potentially partitioned, and you can't get to all the other places you wanted to get to directly, so you know, how do you get that router online so that the network is no longer partitioned so that you maybe can get that router online? Well, you've got to plan for that ahead of time, and that's why in this diagram there were two NOCs with JRCs and one without, just an EST. And so, you know, I don't know, this is some of the thoughts I was having some years ago, and I think it's too ambitious at this point. I don't think it's... I would like to rip it out unless someone else thinks it should remain.
Toerless Eckert: You can assign something to me, I can think about anything ACP related.
Michael Richardson: Okay, please think about this and let's think about realistic real scenarios that we might know of, ideally, you know, with real ISPs kind of thinking about this, how would this work, where would we report... where would we do it or you know, maybe back of the table-top, gamification... what's the right word when militaries do game top strategies? I mean, so basically where should the JRCs go? How many? How are they redundant? How does the database replication work if there is database replication? And what does that mean for bringing the network back online after a you know, something happened, right? Whether it's a a flood, a power outage, or just you know, a tsunami or a um just blue smoke escaped, right?
Toerless Eckert: So there actually is a bunch of these considerations already in 8994, we can point to them. Can we speed up just a little bit?
Michael Richardson: Yeah, yeah, I'm pretty much done. So you know, I suggested this table of contents. Ignore the numbers, we will renumber them obviously. That might be the the operational only document. So that's just about operating things. So one document might just be these are operational considerations, this is not about things that you have to worry about while you're building the the thing. And maybe that's the... that's the right answer to merging it but not everything merges into it. And then you wind up with implementation guidance, which is potentially not a publishable document because we don't really need to publish it that way, but we need to talk about some things.
Toerless Eckert: Right. Any questions?
Michael Richardson: Alright.
Toerless Eckert: Okay. So, I'll quickly take this sitting down here. Update on BRSKI Discovery (draft-ietf-anima-brski-discovery). So I managed to get a review from Stuart Cheshire, which is the author of DNS-SD and mDNS. And in response to that, I went from 09 to 11. Did an English run-up, actually for the first time with just actually doing an AI tool. So if folks are interested, just the number 10 is just after the Claude AI English checking. So actually a lot better than the previous tools I was using.
I added text to introduce and expand on the BRSKI terms, so that folks who only understand discovery but not BRSKI hopefully should be a lot more happy with this. And then did rework section 3.5.1.1, which was just trying to explain that when you're deploying DNS-SD in pledges pretty much, that there is a wide variety of ways on how DNS can be set up, how you discover the DNS server so that you can even find where to do the lookups into. Added references to that browsing part of DNS-SD. So hopefully this is all a lot more instructive because I think one of the generic problems that we have is that most of the successful use of DNS-SD is using some not necessarily public domain libraries in desktop operating systems whereas in the pledges we can expect a lot of one-off implementations and I'm a little bit worried that they will then be too constrained to actually be easily deployed in any type of, let's say, environment where they should actually work, but some parameters are different.
So that was that section. And then, yeah, so in the way I defined how the variations are to be encoded in DNS-SD, that was well-meaning but it wasn't well-done. So the real problem is that the encoding was meant to be as easy parsable, so Michael has always been pounding on making everything for pledges easily parsable. So we'd just have a list of strings, each of which is a variation and unfortunately I was ignoring the "should be no more than nine characters long" of DNS-SD RFC and that means we'd be breaking a "should" requirement and it can easily be that libraries don't even allow more than nine characters. So now I have changed the encoding to be one variation key, which is "var" for variation, and then the variations are just the values separated by commas, which is a fairly standard procedure. A little bit more to parse, but unfortunately unavoidable if we want to stick within the "should" recommendations of DNS-SD RFC.
So I think I'll go do one more round before passing it on. And the open issue is still that there are three big IANA tables that IANA did approve. They're... they're a little bit more review I need to do on them. I think I got another early review from IANA, but they will continue to exceed 72 characters. But they really look lovely. I would love them to be in the same format as they'll be on the IANA, and I don't know how to do that without pulling more tricks like converting them to SVG and including them as an image. So I'm going to have some more discussion with the RFC Editor folks to see what I can do because what Michael was recommending some time ago, which was marshalling everything into stupid, you know, list text, will not read nicely in the RFC afterwards. So any other ideas obviously welcome. And that's it on this one. Any comments, suggestions?
Brian Carpenter: Yeah, Carsten is a definition list but it doesn't look nice in the RFC, right? Why why the heck do we have so stringent rules and... I know you you had to do it but yeah, I'm trying to fight the system on that to to to get a nice RFC but if I have to cave in, sure.
Toerless Eckert: Alright. No more questions? Good. Then we'll recapture some time and we go over to the next presentation. And that would be... constrained GRASP (draft-ietf-anima-constrained-grasp). And then slide clicker.
Longwei Zhu: Hi, this is Longwei Zhu from Beijing University of Posts and Telecommunications. I will present our latest updates of cGRASP. The cGRASP is a lightweight version of GRASP which by replacing the TCP with the CoAP, the lightweight protocol designed for constrained devices in IoT. The cGRASP leveraged the reliability mechanism of CoAP to provide reliable signaling services without the heavy overhead of TCP.
cGRASP is defined as an application layer service built on top of CoAP. It reuses the transport and reliability mechanism of CoAP while the cGRASP messages are encoded as the payload of CoAP. The cGRASP mechanism are directly mapped onto the CoAP request-response exchanges. For example, the discovery and flooding process of GRASP are mapped to the non-confirmable CoAP multicast request using the no response option, and the negotiation and synchronization are mapped onto a series of confirmable CoAP post exchanges and using the consistency token to ensure the session continuity.
There are several updates since the IETF 124. On the mechanism side, we have fully designed and optimized the multicast relay mechanism for cGRASP. On the draft writing side, we have formally clarified the typical application scenarios of cGRASP, for example, the edge coordination in industrial IoT. On the prototype development side, we are migrating the TCP-based GRASPy developed by Brian to a CoAP-based prototype, and the unicast cGRASP interaction process is almost done, and the newly defined multicast relay mechanism is to do.
The key update of cGRASP is the relay over CoAP. Since CoAP does not provide hop-by-hop multicast forwarding across multiple links, the cGRASP must maintain a relaying mechanism and function to expand the scope of discovering and flooding. To achieve this, the relaying node must maintain a relay cache to prevent loops and reflooding. And the processing and forwarding steps of relay mechanism is carefully designed. Every relayed message must be checked... check its loop count, and after the loop count check, the message should be encapsulated into a new CoAP request with fresh CoAP metadata like the CoAP message ID and token, and then it will be sent as a non-confirmable multicast CoAP message with the no response option. Upon receiving a discovery response, the relay node should look up the relay cache and forward the result to the upstream initiator via a new unicast CoAP post request and utilizing the cached upstream token. We also advise to enforce a rate limiting mechanism to mitigate excessive multicast traffic.
The prototype implementation of cGRASP is ongoing. During the development I found a challenge. As we know, the cGRASP is P2P while the CoAP is client and server. There is a situation: prolonged negotiation involving a weight message will break the simple CoAP request and response life cycle. If the weight message sender acts solely as a CoAP server, it cannot easily push the subsequent messages when resources become available. For this reason, every cGRASP enabled node must act as both CoAP client and server at the same time. We handle the weight message via a role reversal logic. When a node needs to handle a suspended negotiation, it can actively switch to the CoAP client role. It will transmit the subsequent messages via a new CoAP request and a CoAP context to the peer's listening port, and the combination of persistent CoAP token and cGRASP session ID will bridge the gap between the disconnected CoAP context.
Towards the next version of draft, we intend to add some explicit implementation guidelines for mapping P2P cGRASP to client-server CoAP. And we also intend to provide some concrete interaction examples for the bidirectional context handling. And on the prototype implementation, we will continue to implement the role reversal logic and implement the newly defined multicast relay mechanism. That's all my presentation, hope for your comments and questions.
Brian Carpenter: Sorry, your voice is very very quiet. This is Brian. Thank you very much for playing with my code. If you have any problems with the basic code, please just ask me because you know I can still remember roughly why I did it. I had a question really: is M-WAIT useful? You know, it was included in the original specification because we thought it might be useful when the responding party wants to delay a negotiation beyond the normal timeout. But um, one way to look at this problem is just use a larger timeout and don't implement M-WAIT. You know, I think that's a question you could consider.
Longwei Zhu: Oh, thank you for your question. We will carefully consider your question after the meeting during the prototype implementation.
Brian Carpenter: Fine, very good.
Toerless Eckert: I have a quick comment. You... your implementation plan is only talking about how to implement the design protocols, but it would be very helpful if you actually set up some demonstration with some typical use cases to demonstrate how the new protocol can be beneficial for certain scenarios.
Longwei Zhu: Yeah, the use case will be considered and implemented for the target cGRASP using scenarios after all the basic implementation is done.
Toerless Eckert: I mean, you don't have to wait for the the full version of the implementation. Whatever function you have done, if you can, you know, make that used, you can have that use case first.
Longwei Zhu: Oh, I got. And I maybe will plan to update the application use case in the next draft. Yeah, thank you.
Toerless Eckert: Any more questions? Okay. Next, network service auto-deployment (draft-ietf-anima-network-service-auto-deployment).
Speaker: Here we go. So this was a document already parked for almost one and a half years. The major reason we parked this document, it was already adopted for a couple of years earlier. The reason we parked it is by that time we only have one example use case, mainly focus on the quality transmission scenarios, which actually was good resolved... well-resolved earlier in routing area. It's not some new use case. Although we claimed our framework is for all kinds of network resources. So we parked our working group document. This time we come back we extend the framework to be intent-based. If you were you know stay with ANIMA long enough, you may remember that we actually have intent concepts very earlier back to 2013 or 14. We have very clearly defined a network intent in the reference model of autonomic network RFC, that's 8993. Anyway, now we come back with the full intent-based framework and with more example use cases we are working on.
So the major change from the version we have almost one and a half years ago, we dedicate the 07 version to intent-based mechanism. The 06 version was more generic based on the resource ASA discovery which means you know there's no intent, there's we assume that the network already have some source, some input for you know the service request, whatever. Now we actually have the intent to give us the abstract request from both user or network management.
So we actually extend the concepts of network service a little bit from only the network management to also cover the requests from the trustworthy users. Here I would like to emphasize the trustworthy users because by default the network is not trust the users, but that's why earlier we don't have a generic version to cover the request directly from users. But in ANIMA, we have different assumption. In ANIMA, we have the all the users through the ACP and we have BRSKI which you know guarantee the the security base from users. So now we have the trust... trustworthy user as our inputters, so we can work on it.
Now this framework is generic and applicable to most types of network resources and that also covered in below two new drafts which we hope this time with those three or even more drafts we cover what what we want to do for most of those kind of network resources. Those two new drafts is the definition of the service intent in autonomic networks. We are not going to define the intent for all general use cases but within the definition of autonomic networks as I explained earlier. And we also have more detail mechanism how the intent-based service intent can be autonomic deployed within our autonomic networks.
So with that, the title of our draft is changed a little bit from the generic autonomic mechanism for resource-based network service to be a intent-based framework of service network service autonomic deployment and management. In the introduction section, we reworded the problem statement to highlight the dynamic and diverse requirements from the trustworthy users. We revised the description of the proposed solution to emphasize the intent-based framework. We also update the list of the use cases to better describe that including the quality transmission and difference transmission, in-network cache and storage, also the computing offload. And we newly added a new scenario very specific for the multiple resource management in data center, which is also the limit domain, which is very good use case for our autonomic networks.
We update the terminology section a little bit. We newly added the network service within the context of the ANIMA. We revised the definition to be specific. A service is a customized composite of network resources. We newly added a concept for the service intent to be the declarative expression of requirements that specific network services, serving as the input for the resource dispatching. We update the service initiator, modified the definition to state it receives and processing a service intent by facing the intent into discrete resource requests.
In the service deployment section, we describe the generic procedures of the autonomic deployment and management of the resource-based network services in abstract way and define the autonomic resource management objects which was we already done earlier in earlier versions. We only added the newly added the section 4.1 that covers the procedure how the service intent initiate the resource management ASA for network for service deployment. The rest is the minor editor change for the rest parts.
We also removed section 5, which was a you know major use case as a example earlier, which is the procedures of the quality network transmission service autonomic deployment. As I explained, the reason is one we have more you know network resources, more types of network resources covered. But we move that into another independent draft.
So the next step, that's a little bit mess there for the slides. We will complete the the whole framework together with the two drafts we mentioned. Although the framework draft is not depends on that two new drafts: definition of service intent and the autonomic deployment mechanism. So that's what we are going to do. We already received two good comments from Brian Carpenter and William Atwood and William told me, you know, they already he already have some kind of implementation testbed, which would be very good platform for us to you know do some implementation on it and make the evaluation tests. Yeah, that's it. I guess for the agenda the our two new drafts will be next.
Toerless Eckert: Yeah, they would be next. Any questions? Okay. Yeah, one line of thought to get more feedback would also go back give some overview and try to address NMRG, right? Given how they've been doing a lot of work on intent, they might be interested to look into things that are trying to take intent to the next stage.
Speaker: Oh, you mentioned NMRG, the network management research group. Because they have they have done a bunch of definitions for... yeah, yeah, yeah. why not? I mean, actually, if you guys remember around 2015 and 16, just after we set up the ANIMA working group, I actually run a network machine learning research group in IRTF. By that time, you know, we were too optimistic to think you know, we have enough intelligence to be able to break down the abstract intent to be the network configurations. But that's we don't have that kind of smart algorithm by that time. So that's why the network you know machine learning research group stopped there. But now with more you know intelligent algorithm and also the AI algorithms, we I think that's time we can do more on the intent-based. And we will continue to do that for the network management purpose.
Toerless Eckert: There is also a workshop on Saturday between NMRG and ETSI here, so if you're not staying but you have slides or so, if they still have time...
Speaker: Yeah.
Toerless Eckert: Okay. Sorry, taking notes and sharing slides. We'll get there. Oh, come on, please. Yes. Stop slide, start slide. So now we got two separate presentations. Let's hope we get the right one. Do you like this one?
Longwei Zhu: Oh, no.
Toerless Eckert: No? Okay, then we'll take the other one. Which is the intent definition first.
Longwei Zhu: Yes.
Toerless Eckert: Okay. This one?
Longwei Zhu: Yeah, this one. Hi, this is Longwei Zhu. I will introduce the new draft called the definition of service intent in autonomic network. And Jalu will introduce another new draft about the autonomic service deployment based on service intent.
The traditional service description are inherently connection-centric and focus merely on endpoints and basic transport metric, which is unable to represent quality objective for complex multi-dimensional tasks, such as the new emerging services like the interactive media and AI inference, which require more than a... more than just a network path and always strictly constrained by the coordinated use of heterogeneous resources. So we think we lack the semantic to express cross-resources coordination constraints. For this reason, we introduce this document and focus on the semantic model and format of the service intent.
The service intent is defined as a structured and machine-interpretable declaration of design service objectives and resource constraints across the heterogeneous infrastructure. In summary, the service intent is outcome-oriented rather than configuration-oriented, which enables the autonomic service deployment.
The service intent is defined with a concise format including two part. The first part is the metadata for identification and life cycle management. And the core part is the intent content, which is defined as a structured object that specifies constraints across the multi-dimensional resources. There are three type of intent content object: the network resource requirement intent, the storage resource requirement intent, and the compute requirement intent.
Recently we have received some active and valuable discussion about this document. We have got two key feedback from Brian. The first one is the need to formalize the intent data format with JSON or CDDL. The second is about how to handle the hard problems of the intent scope. For this issue, we think the existing ANIMA architecture and protocols like BRSKI and ACP will be helpful. Towards the next version of draft, we intend to add some clarification to reference existing ANIMA specification for the intent scope issues, and we also intend to standardize the semantic definition into strict CDDL or JSON schema. That's all my presentation. Let's move to the autonomic service deployment based on the service intent.
Jialu Du: Okay, good morning, ladies and gentlemen. My name is Jialu Du, a student from Beijing University of Posts and Telecommunication. Today I'm very honor to share our draft work, the autonomic deployment mechanism of the service intent in the autonomic network.
Just listening the two draft just now, I think you are very familiar with some conceptions, such as service intent, service instances and responders. So our objective of the draft is to translate the high-level service intent into some resources requirement and reserve them across the network by some negotiation and mechanisms. So in short, we just we have three key point. The first one is a intent phrase. In this step, we will have a intent we will translate the service intent into a structured requirement. And then the negotiation and then the we will compute the routines and select the responder for the for the negotiations node. In this ways, it can according to the current resources and as well as the intent limitations to find the nodes with negotiation each other. The last step we will have the negotiations. The initiator will created a GRASP message which will carry the requirement and may send to the responder. After the negotiation, the users responder will deploy the resources.
So our work is based on the user's intent. We think it is very necessary because you can just imagine a service will have a flexible QoS need. And users and operators cannot and very hard to express the exactly valued for the intent. But they will very prefer to have a to prefer to use the natural language to show it. So by the way, we we just want to design a standard method to translate the natural language into the structures user's resources user's requirement.
Now I'm very glad to show you the intent-based service deployment. We can see this figures. Users may use the descriptions of the natural language and it will submit to the initiators. When the submission, the initiator will have the model can intent the pricing the the high-level user's intent into three different types of resources, just the network, compute and the storage. After that, the initiators will selected the responders and have a negotiation process. When we have the negotiation, we just use the different label to show different type of the resources. You can see the left one is the network resources and the right is a compute and the storage. When we have finish the resources, finish the negotiation, the responder will deploy the resources.
Just now we we considered two scenarios about the how to choose the responder. The first is we just think use the routers as the compute device. In this case, the initiators will both will consider the joint both the select the path and the user and the nodes sections. Another one is simple because it just it just need to access the compute and storage service. So in this case, some in this case, we can just choose the node first and then to have a compute root to communicate with the forward node each other.
Now I want to show the negotiation process about the initiator and the and the responder. First, the initiator will have a will created a GRASP message. It will carry some intents and the proposal list. The right we can just show our extend of the message object. We can see we just add two structures: the intent and the proposal list. The proposal list means how many resource can the responder provide for this service. Next, the two node will have the negotiation process. It is will several times until the initiator accept the negotiation.
After the negotiation, the node will notice all of the responders to deploy the resources. In this process, first the initiator will first collect the all of the proposal list and have a check. After the checking, it will flood the message for all of the responder. After after that, the responder will have the deployment of the resources.
I want to show you that it is a dynamic life cycle process because when the work is continuous, if the resource states were if the resource states have changed, the responders will also send message for the for the node and have a negotiation again until it is satisfied for the resources requirement. After the task was finished, it will the all of the responder will relieve their resources.
Now is our feedback for this work and our next step work. In the future, we just we can consider to use the dry run AS for the RFC GRASP for our release for the resources. And we will have a check for the format of the message. That is our presentation. Thank you for your listening.
Any questions?
Michael Richardson: Hi, Michael Richardson, Huawei. Um, I was just wondering, was there any... I've seen a lot of stuff about intent. Sorry, I just walked in. I haven't read any drafts, but I was wondering if there was any alignment with the TMF 921 TMF intent API? It looks very similar.
Toerless Eckert: remind me of the SDO that's from...
Michael Richardson: TMF.
Toerless Eckert: Okay.
Michael Richardson: I think we can take that offline. Yeah.
Toerless Eckert: okay. so i'll double check the and encourage you to invoke more discussion in the mailing list. Oh, that's fine. I not only for this new draft, also for other new drafts, I would like to remind the authors to try to invoke more discussing in the mailing list. We will see the feedback from working group to see how it you know, we may process it later. Yeah.
Okay, next. Kehan Yao.
Kehan Yao: Hello everyone, Kehan from China Mobile. So today's topic is about GRASP objective for CATS metrics distribution (draft-yao-anima-grasp-objective-for-cats-metrics). It is a zero version of this draft. So I'm wondering if ANIMA is interested in the draft.
Yep. So a quick background for what is CATS. CATS is about is a TE (traffic engineering) approach aiming to optimize traffic steering to service instances by jointly considering dynamic compute resources and network states. So you can consider that traditionally we want to do TE, you are selecting a path. And now, considering that the service providers can provide both computing and network service, you can select both network path and a service instance.
So what's the relationship with ANIMA? So CATS right now is a working group in routing area. We have do like a use cases and requirements, we have the framework will be publication soon. And also the CATS metrics definition will ask for working group last call. So next we will start CATS solution. So CATS require, you know, distribution of the computing metrics across the network to enable the the next stage is a path selection decision making. So we here we need a proper signaling protocol for metric distribution. So we see that GRASP is a potential candidate which fits for like a distributed deployment model.
Okay, so this document's goal is like: we want to define a unique GRASP objective for CATS metric distribution and specify data encoding format for encapsulating CATS level 0, 1, 2 metrics according to CATS metrics definition. And then we will standardize two GRASP-based metric distribution schemes, like active flooding for proactively disseminate the metric and then on-demand synchronization that the one of the network decision maker will to ask for the ASA on the computing node for metrics. And then we will define like message format, processing behaviors and cache management rules for ASAs.
Yeah, here was some basic introduction about the GRASP objective for CATS metric distribution. We will, you know, define a unique GRASP name called "LocalZone:CATS-Metric". So it's an intuitive... it's a tentative name, so and we welcome comments from ANIMA on whether the name is correct or some valuable suggestions on this. So basically two parts. On the first, "LocalZone" represents that the single domain you deploy CATS service. And "CATS-Metric" on the after the colon is represent the you want to distribute CATS metric, it's a objective. And then about the whole data structure, here we use CBOR format. I know that I already received some comments from the list that why you don't use CDDL. So I'm sorry, I'm not expert here. I'm trying to learn CDDL and I just give an intuitive expression on CBOR. And I will seek for feedback from the list and improve the document.
And then some about the distribution schemes. About active flooding is basically based on GRASP M_FLOOD method. And then on-demand synchronization is basically depend on like two messages, like a request synchronization and message sync. So we have, you know, embed some CATS metric into the message and then to implement... for implementation.
So for the next steps, like you know, just as I mentioned, CATS are starting to focus on solution. So basically the stages for CATS is like: you need to first discover services, and then you collect metrics, and then distribute metrics, and then for path selection. So for metric distribution, we need signaling protocols, for example, BGP, GRASP, etc. So as CATS working group suggests, detailed protocol extensions are left to working group that incubate this kind of basic signaling protocols. So we authors come to ANIMA for soliciting GRASP experts' technical advice. And we authors will coordinate CATS with ANIMA on this draft. Thank you.
Speaker: Yeah. thank you for the draft. so i just would like to know what's the attitude of the CATS because CATS is another working group, exactly. so they already defined the CATS metrics, right? exactly. yeah. so do they think that you know anima or grasp is a tool protocols for them to distribute the metrics?
Kehan Yao: I think right now we haven't decided what protocol to distribute CATS metrics. We have several potential candidates, but we need more analysis on existing protocols' applicability for distribute CATS metrics. So we are just at this stage and no more. So we encourage people who interested in this area and you know, join this discussion. Thank you.
Speaker: Okay, because that could be the official way IETF work is one working group make the use case and make the requirements for another working group. That happened in 6MAN and DHCP working group earlier many times. So because that will you know avoid the duplication efforts for multiple solution to solve one single question. So we would encourage you know to get some kind of conclusion or official attitude from CATS working group, then we would you know very glad to to process if you know CATS working group reach the consensus they would like to use GRASP as their protocol tools to distribute the metrics, we would like to work on it.
Toerless Eckert: So I talked with the CATS chair, so the first thing to do is to have an applicability statement for CATS for a particular proposed solution, so we need a CATS document to propose a GRASP. Then obviously how to do it would be ANIMA. And then I think we'll also have the dependency, the draft that I'd been presenting ago, which is kind of how to most simply deploy GRASP with security without our whole ACP stuff, right? So ultimately, it sounds like a good opportunity, but I think we would start out with the applicability statement in CATS because if CATS likes it, then we can do the ANIMA work. Kind of we're kind of the... they have the use case, we can provide the technology.
Kehan Yao: Exactly. Yeah, I think CATS is just starting to work on the analysis, so I think it's good.
Toerless Eckert: Yeah, so Adrian was saying, you know, write the applicability statement, present it, and then we can go from there.
Kehan Yao: Yeah, yeah, I see. Yeah, thank you.
Bin Liu: Bin Liu from Huawei. Thanks for the presentation. Personally, I think it's a very proper leverage of ANIMA technologies to do this thing. And two comments. One is that, for me as an ANIMA guy, I'm very glad to see this to bring into ANIMA working group, but I don't know whether there will be some argument why use GRASP rather than IGP or BGP? Personally I think GRASP is efficient and maybe much more lightweight than using the routing protocol, but I don't know whether there would be consensus among the CATS people and routing area people. The second is that just as Toerless pointed out, we need to decouple the ACP with the GRASP. And I think it's a common issue not only regarding to this specific draft. and i think it's really important. and if we can do it in the working group level that it is allowed, i think it will bring us much more useful use cases. Yeah. Thank you.
Toerless Eckert: Thank you. I hadn't brought up the draft today because we'd be running out of time. I was just saying that for the CATS story we'll need it too. Obviously I'd love to see it anyhow in ANIMA, yeah.
Kehan Yao: Thank you.
Toerless Eckert: Okay.
Bin Liu: Do I still have time?
Toerless Eckert: We just have four minutes, so I think it'd be cutting off time.
Bin Liu: Okay, okay.
Toerless Eckert: But it's it's in the meeting materials and please bring it to the list first and then we'll bring it up in Vienna at the latest.
Okay, let's give you back one minute of your time, I think. Thank you very much, everybody. Um, if you feel bored anytime, just you know, go to our repository, look at the drafts that are, you know, not through yet, review them, provide comments, questions. We always love to get more input. And seriously, we prefer the most stupid questions first, right? Because the biggest problem we always have is that everybody who's working on the stuff is an expert and doesn't see anymore what, you know, normal users are asking themselves about it. So never feel shy about it. We'll always appreciate the the more the stupid the better the question. Seriously. Um, and otherwise, thank you very much, and hopefully you have a great rest of your week, and hopefully also see you in Vienna then. Bye-bye. See you, guys.