Session Date/Time: 20 Jul 2026 12:00
[00:00:07] Joe Clark: Alright. Hello, everyone. How's everyone doing? Good? Excellent. I see we have representation from the World Cup winning Spain in the room. Excellent. If someone in the back wouldn't mind trying to close those doors, I was here in NMOP, and it got really noisy, from the hallway. You are in the IETf-one hundred twenty six ops area working group meeting. I am one of your hosts, Joe Clark. This is my other host, Benoit Claise. Say hi, Benoit.
[00:00:36] Benoit Claise: Hi, Benoit.
[00:00:38] Joe Clark: Thank you for being here. As with all IETF meetings, this is covered under the IETF note well. If you've not seen it, please scan that QR code. I'll leave this slide up here for you to read. This is very important. It covers all of your contributions and it covers the fact that we all want to work with respect for each other. Alright. We are also using MeetEcho. MeetEcho is not just a remote participation tool, even though we do have, several remote participants. It is also the tool that you wanna use here in the room in order to join the mic queue. So we do ask that if you are in the room, you join either the, light version of the MeetEcho tool or if you do join with the full version that you mute your microphone and your speakers so that you don't cause a feedback loop. If you have questions and do want to join the mic queue, please use the raise your hand, feature of the MeetEcho tool and then you can get in line. This helps us keep the, who's participating, and it helps for the minutes. And speaking of minutes, we have our distinguished, secretary, Chong Feng, over there who will be helping. I've pasted in the Zulip slash chat channel the link to our minutes page. If you wouldn't mind, especially if you are speaking, after you sit down, if you could go there and make sure your name and this includes people who just come up to the mic, make sure your name and what you said was properly reflected in the minutes. That would be very helpful for us after the fact. We have put forth an agenda. Hopefully, you've had a chance to see it. If you have, you may be thinking you were in the IPfix working group meeting, but that is not necessarily the case. This is opsawg. And I mentioned MeetEcho. And if there are any technical issues, you can report them in the chat, if you can, and and we'll try to get the MeetEcho team to address them. Or you can come to the mic, and again, we can try to relay that over to our excellent MeetEcho team. I said, I'm Joe. This is Benoit. Chong Feng is our secretary. We had the minutes. We have the materials. We're ready to go. So let's take a look at what has happened in this illustrious working group since last we met in Shenzhen. We have had several RFCs published. I want to congratulate the working group and the authors and all of the participants. Thank you very much. In particular, guidelines for characterizing the term OAM. It was definitely a village effort to get that one through. So again, we thank everyone who participated. This is great work to see us moving not only in specific, like deep areas, but broadly, which is what opsawg tends to do. We're we're creating standardization broadly where it is important, and this is a good thing to see. We're also moving documents forward. We've got a couple in the RFC editor queue. We'll reflect on our milestones in a second. Rashad kind of inspired me to do that in NMOP. And we have a few documents, with the IESG with, with our ADs right now. Of note, and I'm trying not to conflict interest here, we have a document in working group last call, which is 5706bis. Benoit and I are both coauthors on this. So all I'll say is because the IETf came up around the time of last call, the person running consensus, Alvaro Retana, has agreed to extend the last call so we have more of an opportunity with all of you being here in at 01:26 to provide feedback. So if you wouldn't mind, please read the document. And if you have comments, support, critiques, please post those to the opsawg list. There are a set of other drafts, some of which are not going to be presented here. In particular, PCAP is not going to be presented. But the good news is, Michael Tuxen provided a shepherd write up on the historical PCAP document, and that is now in Mahesh's hands. So that is a good thing. We still need a shepherd for the PCAP, now generic, the NG draft. So if you are interested in stepping up on the participation front and acting as a shepherd, let Benoit or I know. Let us know you're interested. And Benoit, you wanna talk a little bit about alternate marking?
[00:05:27] Benoit Claise: Right. So I am the shepherd actually for the IPfix alternate marking document. And this is a group of documents because there is one Yang module. Actually, there is a second Yang module. There is a deployment guide. And, the conclusion is that all these documents are interconnected. And, by the way, whenever you're going to present Giuseppe, even in your presentation, you put all the presentation together even if you need to present on a single draft, which proves the point that they must progress together. So that's a command we made. Why not just move this document to IPPM or at the very minimum do the last call together? And maybe one more thing about the IPfix. Is it the right time to discuss? Sure. So IPfix, we will see that we have a couple of documents that are IPfix related, and we are not specifically the IPv6 working group. So most of the time, those IPv6 documents relate to technology which is developed somewhere else. And you see one about beer, for example, one about BGP. And exactly like Yang, it might happen directly in those working groups if you believe that you will have more feedback or better technology specific feedback. Obviously, we're here to help because we know about IPfix. But the point that we want to make with Joe is that it IPfix rated documents don't have to be in this working group.
[00:07:01] Joe Clark: Thank you, Benoit. I said milestones. So Rashad did this in INMOP and I thought it was a great idea. This may be hard to read, but these are the completed milestones from our charter that we have accomplished, that you have accomplished. And so thank you very much. We're making excellent progress. As for pending milestones, the good news is, as I mentioned, we did we were a little late, but we did get the historical PCAP documents submitted to the ISG. We still were falling a little behind on NG and Benoit just talked about alternate markings. So we are moving that forward, but there are other documents that need to move forward at the same time there. So I think we've been fairly good on our the last recharter, the milestones that we put forth. So thank you and congratulations to the working group. Now we mentioned Benoit teased a mention of this with the IPfix thing. We don't tend to get a lot of reviews because we're not that in the t shape of things. We're not very deep. We're very broad in what we cover in opsawg. What we would like to recommend is as opposed to just having us as chairs or Chong Feng as secretary review, If you especially with these IP fixed drafts, if you can't go to the technology area to get the reviews, ask fellow IP fixed draft authors, hey, would you review my draft? I can review your draft. We wanna make sure that we keep the discussion the discussions as vibrant as possible. And we focus on the interest that this working group wants to have so that we're able to get this work move forward. They're able to meet any, objectives that we come up with, any milestones that we come up with. We can't just be the chairs reviewing things. So it's incumbent upon you as authors to find the reviews and get those people, to provide the reviews on the, on the mailing list. Something that Paul Aiken has been doing recently with Claude, it's helpful. It's good to get a different perspective perhaps, but we want to also get those human reviewers to step forward and provide their comments. There is going to be an AI ops side meeting on Friday. Believe it or not, this is your one respite from AI. There are no AI sessions in opsawg this time. This time. However, this side meeting is gonna be very interesting. Mahesh is hosting it. He's got a robust agenda up in the wiki. Encourage you to read it. And if you have time Friday morning, please come by and join in the conversation if AIOps is something that's of interest to you. Moving on to our agenda, I'm not going to read it all to you. Hopefully you did have a chance to look at it in data tracker. We do have quite a few IP fixed documents that will be presented today but I will stop for a second and see if there's any agenda bashing to be done. Not seeing any, so I will highlight this red text before I hand it over to our first presenter. Your time as it's been allocated includes discussion time. So please, if you have a lot of slides, try to get to the points that you want to raise and get discussion from the working group while we're here in Vienna. And avoid just reading the slides. Let's get to that discussion because that's the fun part. That's where things get done. With that, I think we are ready to go to our first presenter. And that would be you, Thomas.
[00:10:45] Thomas Graf: Thanks a lot. Ah, perfect. So, there are a couple of updates on the export of gigabit passive optical network IPfix document. As you're already aware of, we have two ipfix entities covering the port ID and the p t I on the the gem header. And made me aware of, actually, there is also an x gem header. And in this Xgem header, we also have a port ID. And there are also a couple of other properties like the the payload length indicators or PLI, the key index options, last fragment, and header error control. However, those are more for, like, tracing debugging options and less about accounting relevant things. So it's really the the port ID, and we need to make sure that in the IPFIX document, we are addressing that as well, and that's how we did it. So we have the gem point, the g pon gem port ID, and in there, we have the references toward the gem and also the x gem header. That's basically the main thing. Just to review the first document revision we published in April 2025. Then quickly we had from Polar and IANA review, the opsawg basically adopted it in September 2025. And then in March 2026, we had the first implementation. And now we received a review from Chong Feng and also from Paul. Chong Feng, I was able to integrate from Paul. I still need to do, but afterwards, I believe the document is ready for Working Group last call. Any questions, comments, tomatoes?
[00:12:47] Joe Clark: That was quick. Thanks. I think we can do a working group last call.
[00:12:51] Warren Kumari: Okay. Good. Thanks.
[00:13:05] Joe Clark: Scheduled OAM. Chin.
[00:13:19] Qin Wu: Okay. My name is Qin Wu. So I will give update for this young data model for nanog diagnose using schedule sequence or OM test. Document status. And since last ITA meeting, actually, we get a a summary review, especially from Joe Clark, and, also, we encourage other people to have to review. So we do have, you know, Hans and Hongwei and also to provide additional comments. So thanks for that. Actually, some of these outstanding issue has been discussed, and we try to resolve in the in this version. And latest change compared with previous vision, such as we justify why order by user, and we add clarification on execution counter. And we also make a change, for example, a temporary parameter, make replace as a young statement. And, also, we try to, you know, reuse some scheduling grouping in already published out c. And so we found actually a frequency and interval should both require, so we make such change. And we also change the young data model prefix. And and, also, we, you know, follow the security consideration template and to make it come you know, comply with, I've say, ninety nine zero seven. But we do have one issue want to discuss in this meeting. It's about the EID description. And so let's review some of changes we have. Actually, the first is change a temporary parameter into a young statement. Actually, these comments from handset actually but we found some mistake, you know, this identified by actually. So we see the order by the user is not, you know, attribute or parameter. It's it it actually is a young statement. So we mix this fixed as a back, actually. So this change we made. Second one is that we clarification on execution count and order by. I think it is coming from Joe Clark. And, originally, we use a different definition. We call the number exclusion. So this so we think the definition is not very clear, so and lack clarity. So and, also, we need to clarify how to use this execution count and order by user. So based on this, actually, we change the number execution into the execution count based on the Joe's suggestion. And, also, we see we we do set the default value for the execution count, but this actually, you know, is not necessary, actually. So we remove this, and also we, you know, clarify how to use auto by user in this proposed change. And, yeah, last this last one actually is about the router ID, you know, this whether this route route ID is sufficient. You know, currently, we, you know, define any ID as a stand alone parameter. Not not actually, we we reference, you know, root ID defined, obviously, 8294, actually. This really apply to the all the router type. But so some common risk, you know, by is think whether it can be applied to long router elements like l two switch or firewall. And so it seems the current definition is quite limited. By the way, you know, revisit this definition for the router ID in the eight two ninety four, and we see this also can support a various different control plan protocol or layer two protocol. So the question to chair and also working with whether this, you know, route ID is sufficient. And and if not, actually, we have a follow-up, you know, solution for this. I want to hear some feedback on this.
[00:17:41] Joe Clark: Feedback on question? Okay. I'll go. Is it sufficient if the network element isn't a router?
[00:17:58] Qin Wu: Yeah. I think we can cover various different element, not need me to root her.
[00:18:06] Joe Clark: So what would you pick for that 32 bit number then?
[00:18:11] Qin Wu: Yeah. I think current you not about, you know, 66 64 bit or it's about, you know, whether we can apply to some other network element type or, like, a firewall layer to switch and maybe Right. And host the so we
[00:18:36] Joe Clark: I mean, I think you would have to give guidance as to what to pick for the value of that. Like, I'm thinking of of layer two switch that could have OAM Yeah. Scheduled on it. What would I pick? Its management IP? I mean, I I guess what I'm saying is there would need to be some level of guidance if if if something if if it's not something you're already thinking of is, like, the router ID. If it's not a router, what would I pick? What would what value would I recommend I put there?
[00:19:09] Qin Wu: Yeah. Jeff? Jeff?
[00:19:14] Jeff Haas: Yeah. So a few observations Jeff has. Context really matters. So for routing protocols, you know, this ID is gonna work great. You know? So for things that have tiebacks in OAM to routing protocols is the thing that's exposed. In the context of the individual protocol, it makes sense. I think it's ISIS that has a v six version of a router ID. No. This means that you need an additional element as the correlator in that context. The place where this gets messy is that the protocols, even on the same device, don't always have to manifest the exact same router ID, although it is incredibly common. So this means that you need to be capable of handling the context in more than one protocol. The second piece, as you're talking about, is what happens is if this is not tied to an IP element or a routing element. You're still looking for a magic number to correlate. This is no longer the same thing or sufficient. So don't use this as your only key. The better way to treat this is is, you know, when you actually have something that you can compare into as a foreign key, this is useful to correlate data. Just don't make
[00:20:25] Warren Kumari: it the unique key. Yeah.
[00:20:29] Qin Wu: That makes sense. Thank you. Yeah. Actually, we, you know, come up with the the follow-up issue. You know, if sync is not sufficient, actually, we have three different proposal. And I think we already have an ID or node ID, you know, defined network topology based model. Actually, we can consider to, you know, import these type definitions. So, yeah, we don't need to so this is one option. The other one is whether we can import some type definition from IV, that we inventor model. Actually, this I think has actually gives such kind of proposal. So we have, you know, proposal three actually are quite different quite similar actually. Just use a reference about a in sense, actually, is is the same actually, similar to the type definition in the second proposal. So, yeah. We haven't decided which which proposal we should take. And yeah. I think yeah. This is what do we have?
[00:21:39] Joe Clark: It it might be good for the authors to settle on one that you think and when float that out to the list and say, you know, this is what we think is the best for these reasons. What does the working group think?
[00:21:52] Qin Wu: Okay. I can summarize for this option and, yeah, we can give our preferred options. So get people some feedback, yeah, so we can see how to close this issue. I would agree
[00:22:04] Benoit Claise: with that as an inner contributor because it's not something specific to your draft. This is a problem in the IETf. We've got three IDs there. I could find you some more, the loopback zero IP address, the UUID, and the IETf hardware. So we know that you've got this issue, so pick the one which is the best to you. And to make the link with Jeff, At some point in time, there will be connections between these IDs somewhere, but not specifically in the Yang. It would be a dream to have a single ID. We don't have it.
[00:22:32] Qin Wu: Makes sense. Yeah. Thank you. Yeah. Last slide, Yeah. We did get a few people review, and so we want to ask chair whether he's ready for working with last call or we can have early young double review.
[00:22:47] Joe Clark: So I think because of what you just described, maybe working group last call isn't ready yet. There's still a chat a question to be answered, a fairly substantive one. That said, I was surprised that we haven't gone for a Yang doctor review for this. So I think we can do that as an early review anyway.
[00:23:03] Qin Wu: Thank you. Great. Yeah.
[00:23:05] Per Andersson: Yeah.
[00:23:08] Qin Wu: Okay. Thank you.
[00:23:09] Joe Clark: Yeah. Thanks. Oh, you took control. I took I just released it. Okay. Now, please do that. There we go. It works. It's going to work, hopefully. It's gonna work. I promise. You have every reason to trust me.
[00:23:54] Yunsong Liu: Yeah.
[00:23:56] Qin Wu: It works.
[00:23:58] Giuseppe Fioccola: Yeah. This is an update. As Benoit mentioned before, this is an update about the IP fix alt mark document, but I'm going to provide context and to because this document is part of a set of documents from IPPM. So I'm using the same slides that I will present to IPPM in the next days just to give context to this work. So this is the main document about the deployment framework. I'm not going to present all the slides, but I will just focus on on the key points. So this is the main document about the deployment framework. As you can see in this document, there is the overall framework, the overall architecture about how to deploy the Altmark. And in particular, there are several documents that are referenced by this architecture. The, of course, the young model, PSAP, BGP extensions. But in relation to IPfix, in particular for data export, two documents are are relevant, the IPfix that is in Opsawg and the IPPM on path telemetry young. Of course, these documents have a broader scope in order to define where to deploy alternate marking, control a domain, the type of measurements that can be enabled, and so on. You can look at the document. Yeah. These are these are the changes from the after the working group plus call because this document was already already concluded the working group plus call in IPPM. I'm I'm going to skip this slide. So the other related document, of course, are the young data model for the alternate marking method. This is the reference if you are interested and if you want to have a look. Also, this document was in working group plus call in IPPM, and we apply the the changes that will be described in IPPM in the next days. Also, the the draft on the on path telemetry yang that included both alternate marking but also IOM yang push extensions. And these are the changes from the last version. And finally, related to WG, we have the IP fix document. Yeah. Just a quick recap. This document is quite straightforward. So we just request Ayana to create new information elements because with alternate marking for those of you are familiar with this methodology, each node need to export telemetry data at each period for each monitored flow. And it possible to use a combination of existing information elements and new information elements. The existing information elements, of course, are source address, destination address, protocol, and ports that are not mandatory to be used. But new information elements are really important because are related to the flow monitoring identifier, the loss flag, the delay flag, and the period ID, which are defining in the RFC ninety three forty three for I p v six and for MPLS in the ninety seven fourteen. Thanks to Benoit. So for the detailed review of the comments, we address most the all the comments in the in the last version. In particular, I want to mention that we improved the description of flow aggregation, correlation, and measurements. We also changed the name to be to be aligned with the naming convention, so the naming of the information elements. We also clarify that there are two options for the computation, a centralized and NMS computation and the computation on each node aligned with RFC ninety nine fifty one. Of course, we also revised the cross references between the different young and IPfix documents in order to help the implementer to understand what are the corresponding parameters between yang and ipfix. And, of course, we added the operational consideration sections. Just a few words about the next steps to stay in five minutes. So the first two document, the deployment one and the alternate marking young just concluded working group plus call. I I agree that, of course, the two young model would need to be reviewed together to check the consistency also together with the IPfix alternate marking document. The IPfix alternate marking document is quite stable, can be ready for a possibly a joint top cell WG IPPM working group plus call. So, of course, comments, question.
[00:29:16] Mahesh Jethandani: So, Mahesh, on the last document, the IPfix-alt mark, I believe there was a expert review from Paul Atkins, and he had two substantial oops. I should sorry. Substantive comments, and I I didn't see a response necessarily on the mailing list. Have they been addressed?
[00:29:38] Giuseppe Fioccola: Yes. Do you mean to IPfix the the IPfix documents? Yeah. Yeah. The the yeah. Yeah. The the doc the the comments should be addressed.
[00:29:50] Mahesh Jethandani: I I maybe then I must have missed that email then. Okay.
[00:29:56] Joe Clark: Speaking of Paul. Paul?
[00:29:59] Paul Aitken: Paul? Yeah. I'm just gonna make the same comment as Mahesh just as I did not see feedback, and I was expecting to see a new version of the document or or comments or something before I do the performance metrics review.
[00:30:20] Giuseppe Fioccola: Okay. Yeah, we can we can further discuss. Anyway, I for sure I have address in my local. I don't remember, I have to check. But in my local version I should have a dot address, but now the submission window, it just reopened, so maybe I will publish in the coming days too.
[00:30:41] Joe Clark: Yeah. And don't forget follow-up to the list.
[00:30:43] Giuseppe Fioccola: Yeah. I will follow-up on the list. Yeah. Of course.
[00:30:46] Joe Clark: Thank you. Yeah.
[00:30:48] Benoit Claise: Yeah. Nothing on the list. Okay. Thank you.
[00:30:51] Joe Clark: No. Thanks. Come see.
[00:31:08] Albert Lopez: Hello. So we are going to explain some updates coming from the JAM provenance signatures. In China, we asked for the review in and as well Yang doctors review. So the first version that we updated, it was for to address these comments. In the executive review, we added
[00:31:37] Mahesh Jethandani: a
[00:31:37] Albert Lopez: threat model in the security considerations that they ask in the review. We also have been some we have been talking with Iana and experts on COSE for the the implementation of of that we we brought to China. And we have the opportunity to ex to talk with them this morning. So they told us to ask for a preallocation of the seed ranges to the, and they will comment on that. But mainly, they will just compile that everything works, and and that's it. And lastly, the young doctors review that they bring us the canonicalization of YANG that as we are doing it with different canonicalizations for each serialization using JSON schema JSON canonicalization schema, and XML canonicalization to bring it in a semantic way that can be more interoperable between between different formats. We believe that maybe this can be addressed in another draft as it could be open another for another use cases. And we are looking for proof of concept of this work and find a solution for this. For the next version is what we wanted to bring into Vienna, which were the multi signatures to what we encountered is that using only codesign, you had to add all the signatures at the same time. And with the countersignatures, we find that we can address the same content but at different points in time. So we can provide a traceability of this content, validating all the signatures or just one of them. This doesn't change the causal mechanisms. It just only adds to the header, the new counter signature when they receive the counter another type of device or or collectors. And it doesn't define a new signature structure. This was validated yesterday on the hackathon. We always bring into the hackathons the reference implementation. And lastly, for the the version zero seven, it was just an it's a small detail that was coming from that is is the live ordering the the live ordering that in junk is not a constraint. So in the notification envelope, we delete that paragraph. This is a recap on hackathon project that that we show yesterday where we updated the library to support these countersignatures with the three serialization formats. And it was validated not only with our project, but in collaboration with Jang- poo's predict and also with other type of use cases like attestation for agents. And what we comes next is that we are still pursuing these reviews. For the sec the executive review, we address the comments, and we only need the confirmation that everything was resolved. But in the Ayana and Jack doctors, we have to still work on that. And then the big important thing is the to be interoperable between formats. And that since this Saturday, we have been having a lot of alignments and collaborations with our Jamf provenance signature in in different use cases. We always give our reference implementation. Yesterday, we got a new implementation on on Airline. We we always work on Java. And I would say that the content of the of the draft is mature, but for the for the last call, the only updates would be for reviews.
[00:36:47] Joe Clark: That's it.
[00:36:49] Rob Wilton: Rob Wilson, Cisco. So thank you. I finally got a chance to sort of look at this draft in detail, on the flight out here. I think it's really good work and really interesting. I have some comments. I will put them on the list, but I haven't sort of typed them up, but I'll sort of raise them here. So one of the thing I noticed is the signature you generate is tied to the encoding that you use. So if you have a data pipeline that wants to normalize, say, data coming from a collector provider in JSON and CBOR, you and and say normalize either to JSON upstream or to CBOR upstream, you're going to lose that signature. It's gonna be invalid effectively because the signature is tied to the original encoding. And you change that encoding on the way through, then you're going to lose that. So it's something to think about. I'm not sure of the solution, but just be aware of. The other thing I noticed, you had different I come the name of the head of the security context. You had a leaf for XML and for JSON and CBOR. But with CBOR, you had both the sitting coatings, like the binary identifiers and also the leaf, the string identifiers. And I think that the the the checksum you calculate for those two or the signature will be different. So you might want to split out to have a a CBOR strings and a CBOR type identifiers as two different things,
[00:38:07] Mahesh Jethandani: from
[00:38:07] Rob Wilton: that. And then the last question I had was, it talks about normalizing the Yang data before you apply the signature, which makes sense. That's necessary. It wasn't clear to me in the draft whether that means when you send the data, on the wire, it's also meant to be normalized or it's just the signature calculation, that makes sense. As in are you meant to normalize the data before you send it and then you apply the signature, or is it just the signature calculation that's required to normalize the data?
[00:38:37] Albert Lopez: Okay. Yes. There are other question. I would say that what we do is to normalize it to add it to calculate the signature. But we what we want is to if we want to receive the same content but in a different order to be valid in both ways as for for example, for a young data stores that maybe is represented in a different way, but it should be valid in both ways. This is something that we have encountered with this January doctors review, and we will try to to to do something about it. Okay. Thank you.
[00:39:24] Per Andersson: Hi. Hi, Andre Sean. Thank you for this work. I think it's really great. We were also in the hackathon as well. I'm very happy to see, for instance, countersignatures to be able to have more signatures than only one for the content. I think the normalization of the data, especially at rest, is really important because that makes it able to detach the data, the signature from the data and verify it on both assign it on one end and verify it on on the other end. One thing with that is what happens if you send sparse data. Instead of sending, say, the entire interface's list, you send only three out of five. How does that work at the other end? So that's something to think about as well with existing solutions of Merkle trees and so on and so on. Thank you.
[00:40:14] Mahesh Jethandani: Mahesh. So I'm not going to repeat, I do support both Rob and Per's comment on normalization of the data itself. One question that I did have was around that the Yang Yang Lindt augment structure errors and whether do we know that that's a tooling issue, or is that a modeling issue? And have we resolved that question?
[00:40:38] Albert Lopez: The can you repeat the tooling for me?
[00:40:41] Mahesh Jethandani: So I believe you have an issue with the augment structure errors. I think you mentioned that somewhere. And whether that has been resolved or not, whether that it's a tooling error or not.
[00:40:57] Albert Lopez: I we don't use tooling is something manual. Maybe we can check and come back to you.
[00:41:05] Mahesh Jethandani: Okay. I can probably send you a more direct pointer to I think it was mentioned in one of the reviews.
[00:41:12] Qin Wu: Thank you,
[00:41:14] Joe Clark: Adam. Real quick on our part. You mentioned last call here, but you also have a big elephant in the room. So we would we're a little confused. We don't see if it's stable if you have a a big rather than a small elephant. But you have the elephant in the room. So can you you don't have to clarify it here, but we maybe on list, you can clarify what your intent is. If if you're gonna work on proof of concept and it's gonna change your draft, that feels fairly substance substantive. If you decide that that's for something else, then I think we need to close that issue before we move this to last call.
[00:41:54] Albert Lopez: Yes. What we intended is to move this into another draft because we think that for this draft, it's out of scope or maybe it can be used in in use cases that doesn't require this this jang same representation problem. But for other use cases, for example, when we are working with Kafka, you send the same message, so we don't have that problem. So what we try is to to to up to open another draft and and address this. And after that
[00:42:41] Diego Lopez: I feel obliged to make a clarification. The point is that junk canonicalization is a problem that has appeared. Mhmm. Well, I prefer to call it junk normalization, not canonicalization because that's this generalization is a is a problem that has appeared regarding to the data stores, not to this change of data. So that's why this is for this is intended for this change of data, and it is that that problem that has appeared, we we we have the intention to address it in another document because we we believe that the intention of this document, the original intention is is covered.
[00:43:15] Joe Clark: That's it. So you don't plan any substantive changes?
[00:43:19] Benoit Claise: No. Okay.
[00:43:20] Diego Lopez: What what we plan is that the for example, the the the revision the review from the security area is clear. For example, it's Okay. We have addressed it already, and that's it.
[00:43:28] Joe Clark: Okay. Thank you. Velocee. Velocee. However you wanna pronounce it. Mahesh.
[00:43:50] Mahesh Jethandani: I don't know. Everyone has a different way of pronouncing it. Alright. Thank you. So I think since the last discussion or anything, we I believe we have adopted the document as a work group document. So thank you. So I should probably be updating this slide. So I'm just gonna quickly run through the status, but I really want to spend most of the time having some discussion around at least three questions that group of authors and contributors are working on. Since the last publication of the individual ID was published, we have had six peers and 11 new issues. I won't go through them here. You just go to the GitHub to get all the details. Right now, we have 22 issues that we have broadly classified into six clusters. Probably anywhere from easy to really hard discussions that we need to go through. Some of which we'll I'll talk about in subsequent slides. We have seven open peers that are still under review and discussion. We have a requirement now that at least two authors slash contributors have to approve before any submission is accepted. Any peer is accepted. But now that is a work group document, even that process will have to change. Alright. So the first question that I wanted to post to the working group is, where should the repos live? So we have three options that are being debated currently. The repos where the yang is gonna be developed can be in GitHub. It could be in ITF GitLab. Or the third option actually, the third option is through what we are discussing now is through in our registry. And final option is being platform agnostic where we don't, as such, dictate or define where the repo should exist, but just the requirements for what the repo has to be able to provide. So this is more a question. I can either pause now or wait for people to ask questions at the end. What would you prefer? On this particular question, there are no comments. I
[00:46:38] Joe Clark: have ah, Chin. Great.
[00:46:43] Qin Wu: Yeah. For these several option, I think GitHub is widely used by many working groups. So I favor, you know, the option a. Option b could be another option. It's but I I I not familiar with it, but I checked some of working Google in some other way. They do use a. So so I favor to using the option a. And for INA registration, I don't think, you know, INA is used for you know, to maintain this young data model. So, yeah, that's my thinking.
[00:47:20] Mahesh Jethandani: Okay. So just to you do you do realize that we do maintain AYANA based Yang modules through the through AYANA. So there is a certain amount of precedence to this Oh. Which we can follow if we want to do it for all Yang modules. But precedence is there for us. And the yeah, really that clarification.
[00:47:43] Qin Wu: So you think I have not registered to for the I have not maintained the young data model. Right? That's whole young data model. Okay.
[00:47:56] Italo Busi: Hey, My concern is the timing. We need to develop Velocee. And b and c looks as some advantages, I'm afraid that by the time we develop all the environment, we we delay a little bit the the start of the of the of the experiment. And it will take a lot of time to write down all the requirements to make sure that everything is sort out. So I was wondering whether we can start with option a as the quick and dirty solution and then figure it out whether to move to b, c, or d as the long term strategy. That's my thinking. Thank you. Okay.
[00:48:37] Diego Lopez: I believe that since we are going to change something that has been a long time practicing the in the IETf, I would prefer to see the data within the IETf environment and using using Git like mechanisms very much in favor of of option b even if that implies that, yeah, the maintainers will have to learn a few tricks among other things because the goal, I assume that the goals of of Velocee is not being extremely agile in testing and developing. It's about once you have something that is clear, put there. So it's gonna be I mean, the the the kind of activity is not going to be the full the the full goal of of software development. So let let's keep data within the ITF is my my recommendation or my preference.
[00:49:28] Mahesh Jethandani: So just one comment. I think plenty of people have pointed out that the fact that we are mentioning GitHub seems to imply that, yeah, we have no control over the data. Now, supposedly, we have a relationship, meaning in the sense we are probably paying for that service. And therefore, it's not that we don't have control over the data that is in GitHub. But, yes, it does reside in a third location.
[00:49:57] Diego Lopez: Be because one thing is using it for developing the document that afterwards comes to the data tracker. So it it's perfectly fine, but the at the end, the the the RFCs are in the data tracker and the drafts are in the data tracker, not in the GitHub. So that's Okay.
[00:50:18] Rob Wilton: I can't tell. I hope I'm next in the queue. Robert. So, I think it's sort of almost been raised. I think the question is, what's the archival quality of the data that's required? So the Veloceity project, I thought, was an experimental short term thing to start off with. And then I don't think really matters where you put it. So in some senses, I would shove it in GitHub to make it easy to start off with, but with a plan to move it potentially to GitLab as Diego's just down the line. But if the long term plan is actually, we need to have this stump somewhere where we control and maintain it, and allow it to be developed and, and be around for a long period of time.
[00:50:55] Joe Clark: Mhmm.
[00:50:55] Rob Wilton: Then then GitLab might be a better choice. I don't know quite what the relationship is between GitLab and how if we run that completely ourselves. The last comment I would like to make is regarding IANA. I agree that I think you've got this this choice between where you're sort of developing the young models, and I still think you'll be you'll end up developing, a cutting edge version of it. At some point, you're gonna need to publish those
[00:51:17] Mahesh Jethandani: Right.
[00:51:17] Rob Wilton: To some level of with some level of consensus. And then the point you publish them, I think IAN is the right place to say, okay. Here's the latest latest version of this published and has some level of working group or ITF consensus.
[00:51:31] Mahesh Jethandani: Right. On that I know registry point, you're right that I think we have certain way of tracking that today even with the ANA based modules. So we we could reuse that tracking mechanism that we have in ANA for all young modules. So
[00:51:54] Dhruv Dhody: Drew. So regarding INA, I would not consider this as a clear option for this question because we can't say that INA registry is a repo. It can still just be a registry to point to the latest model. But if you wanna do the actual work of what we wanna do with Velocee, we can't just say that, oh, it's gonna just be. So I think that's a separate question that we need to answer. Now I think when we are having this discussion, it would be useful to say what to write in the experiment. And when you are actually doing the experiment, what mechanism will you choose? So right now, if we have clubbed the two questions together, what we could do is we can say that while doing an experiment, you must have a pro like, if you take option d as as a case that when you are doing an experiment, make sure you have a a repo. It should have these properties. And then each working group, when they are making a decision, they can they can go by what makes sense for them. That would be much more easier for us to make progress. Otherwise, we'll end up debating on this point for a very long time.
[00:53:00] Mahesh Jethandani: So, yeah, thank you for pointing out that yes. Behind the IONA registry is also some kind of repo that is being used. That is true. What I guess I should have pointed out is what is the reference point? Is it a GitHub location, or is it the IO registry? I think that's more clear, that question that we are trying to get an answer to.
[00:53:22] Jeff Haas: Yeah. Jeff, as building on some of the points that Drew made, we have three things that are sort of, you know, occupying this set of questions. One is, you know, the thing that we're using. You know, in this case, we're choosing Git. We know from other things that IATf has used that are open source, that are openish, like, Ursink, that we get ourselves in the trouble long future. We need a path out of being able to recover our data for the future. So that should be a background requirement. Second piece is, you know, out of the infrastructure involved, I've used GitHub and GitLab. Git GitLab is perfectly fine for storing files, and it has one of the worst review systems I've used in years. So usability, I think, is, for the short term goals of this project, something that urges us towards GitHub. And, you know, the third piece, you know, there is where does this stuff, you know, get live and get pointed to. As long as portability is a long term plan, really, what we need is a long term way to find wherever something happens to be. We should expect that our data gets archived at some point and move somewhere else.
[00:54:25] Warren Kumari: Yeah. I I've already solved this for you. It's on my MySpace page. Right? Like this is the problem of if we put this on GitHub, what's going to happen is at some point in the next fifty years GitHub will go away and then we'll be screwed. So as long as we have a plan to archive it from wherever we have it to somewhere else, right, we can can deal with this. But, you know, let's do something friendly for now, but make sure that we have a real plan for what we do when this service actually goes away.
[00:54:54] Anders Starrin: Yeah. Well, Arsenio, Derek's on. We are actually doing this in three g p p already. User prefer a git interface, so a or b for me at least. And three g p p said that they want control. So GitHub is too loose for control. They go with git with an own GitHub host.
[00:55:17] Qin Wu: Okay. Thanks.
[00:55:19] Anders Starrin: I think maybe this is good for a vote.
[00:55:26] Italo Busi: Okay. Italbuzzi again. I have a one comment on the Yana registry, which is along the line maybe to what Rue said. As far as it is today, with Yana registry, you cannot do something which you can do with GitHub like the diff. And in my opinion, if you want the logic to be successful, we need to have a mechanism like the GitHub pull request that forces the reviewer to look only at the changes. Because the big issue I found when we do the biz is because people have all the models. They view all the models, and 99 dot 99% of the comments that you get are not on the changes, are on something that you didn't intend to change. And you spend hours and weeks addressing those comments instead of publishing the changes. So it's very important to me that it's during the review phases, the review is forced to be on some tool that focus on what are the changes. As a final repository, I don't see any issue. But for the progress, I think we need something like a pull request. And then if you go to d, then we have to write it down all these requests. That's why I was saying GitHub as a first step. So we have everything. We know how it works, and we can do better later. Okay.
[00:56:42] Mahesh Jethandani: I've clearly run out of time. So on just question number one, so I'm not even going to try to present the remaining slides. I'll take it to the mailing list.
[00:56:52] Joe Clark: Thank you.
[00:56:53] Benoit Claise: Very good. Good news. You're very interested.
[00:57:11] Kirsty Paine: Hi, everyone. Thank you for giving me some time to present our draft. So I presented it for the first time at one two five, but a quick reminder, we're talking about fundamentals and guidance regarding security operations. In the draft, we go into a bit more detail of what we mean by security operations. But in general, security operators are people who work to defend their network from cyberattacks or recover their network once they've discovered an incident. They typically work in a security operation center or a SOC. It people who work in a SOC might be cybersecurity analysts. They might be network engineers. In the draft, we've we've called all of them security operators, and this is some of the stuff that they care about. So the purpose of the draft is to help protocol designers consider impacts for security operators when they're designing their protocol. It's heavily inspired by the work that went into May, so thank you to the authors for that. There is some text in there to help with this, but it's a wider conversation, so we added it to a separate draft. I should say the guidance in there is meant to be a tool to help protocol designers. It's not a mandate to include these considerations, but it's meant to prompt thoughts about what are we changing, what that how might that impact people, can we mitigate that, can we document that. So since ITF-one hundred twenty five, we received a bunch of reviews, so thank you so much for that. I think we received 11 or 12 reviews, both on the list and off the list, from a range of people with different backgrounds, so that was really useful. And so we've actioned a bunch of that input. I did want to say a couple of words on that penultimate bullet point about more detailed privacy considerations. We've added some text there. That was a really good point that was made in a couple of places on list, because there is perhaps a tension there. Security operators require a really good understanding of what's going over their network, and that, on the face of it, that cut can appear at odds with an attempt to kind of minimize access to that data. In contrast, security operators, if they're preventing data breaches, might improve that privacy. So it really depends on the situation, on the network, on the system, about the required level of observability. This draft doesn't make an attempt to to say what the right thing to do there is. It's it's very much down to, down to the situation. But please do review that section because I think
[01:00:05] Warren Kumari: it's an important one to get right.
[01:00:10] Kirsty Paine: There's a few more additions that we'd like to make. So we received quite fair feedback that the original zero draft had a lot of focus on enterprise, and perhaps less on operators, or large scale operators. We've attempted to add some text there in terms of thinking about dynamic networks or large scale networks. But that's not really my area of expertise, so I'd really appreciate any input of text that that can help out with that. Similarly, on logging, at the moment, the guidance is quite general to be broadly applicable. But if you have specific examples of where logging is useful, where there's value, where change in protocol might affect that, that would be really useful for kind of motivating examples. We've got a couple more outstanding reviews from the list that we didn't get time to review before, and to action before the cut off. So thank you to Adrian, and thank you to Mark for those. In particular, from Mark's review, he provided really good insight on the section regarding tooling, where we can I think we're gonna change the focus a little bit to focus on the capability of the tooling rather than the specific tooling products themselves? So so we'll look to do that in the next version.
[01:01:35] Mahesh Jethandani: Is that working?
[01:01:36] Kirsty Paine: Okay. Next steps. So there's a few things, for us as the authors to do, as I just mentioned on the on the last slide. We'd also really appreciate input of text from the working group, where you will have expertise that I don't have. The other thing that we're seeking, in terms of next step, is some guidance from the working group, from the chairs, about what we need to do to move this draft closer towards a place where it's ready for adoption. We think we've got some quite good text there, but we're looking for support, some interest, and any guidance about where we are with that. So I'll pause there. Thank you.
[01:02:20] Joe Clark: So, Chong Feng and myself, we reached out to some of our colleagues, Mark was one of mine, that gave feedback on this. But they're not typically IETF, let alone or opsawg, let alone IETF contributors. So I have we have a poll for you here in the room and online. Are you interested in seeing this work progress in opsawg? This is kind of an unofficial kind of get towards that adoption poll. This is interesting work, I feel, as per speaking personally from a security operation standpoint. But do we have interest in this working group in seeing this progress? Yes, no, or no opinion? Oh, I was just gonna say, I think the velocity has slowed, but people are still voting or sorry, showing hands. Well, I think you see most people and I and I I don't know if the no opinions have read the draft or not probably not read the draft yet. There does seem to be at least one person who says no. I don't know if that person wants to make a comment as to why they don't feel or they're just not interested. Maybe they that's just a personal thing. But there are some support for yes.
[01:04:10] Benoit Claise: And one thing I would like to observe is that I'm not surprised by the results because, actually, this is the ops people. And we're not really into security. I mean, we could say knock and sock. They work together, but they are not the same people, which was also the feedback that's what you've been brainstorming on trying to reach out to some real real security experts. So we don't want to say that this is bad in opinion. It means that the people here maybe don't have the background to review the draft. Right?
[01:04:43] Joe Clark: Jeff.
[01:04:46] Jeff Haas: Thank you for saying exactly that. So I spend a good chunk of my ITF time dealing with the fact that the security people live in their own very special world. And I think if you were to go to the security open meeting SAG, if you haven't actually done so already, I think you're going to see exactly the same feedback in reverse. They're gonna say, you know, the security pieces here are clear, but you're really taught having an ops story. There is no single home for the joint work. So so the best thing you're gonna be able to do without actually getting the groups to decide to cooperate together and you can actually do you know, pick one home for the work and span it across places. That does happen regularly in the IETF, but that doubles the amount of work that you end up having to do to join it out. What you're really better off doing is finding some willing participants as a design team type behavior, working on it across the working groups, then last calling both places with the chairs.
[01:05:42] Kirsty Paine: Thank you. That's really useful advice. We have shared it with the the SAG mailing list. But, yeah, a little bit work more work to do to to get people involved. Thank you.
[01:05:58] Shunwan Zhuang: Yes. I I actually, I have mentioned this before because I think most people in your have enough security background. So it's very difficult for for us to make the decision whether this work can be can be appropriate or can be useful, can be useful for writing a future document. Yeah. That's my concern. Okay. Thank you.
[01:06:36] Benoit Claise: But anyway, you've got things to do in the meantime.
[01:06:39] Kirsty Paine: Yeah. We've got some work
[01:06:39] Thomas Graf: to do, but thank you.
[01:06:41] Joe Clark: And I and I think you've got as we just talked about privately, you've got some people who can bring more feedback to the list. And if you can have the SOG people, if they've given you any feedback, tell them to cross post over to us as well.
[01:06:57] Kirsty Paine: Cool. Thank you. Yeah. As we said, we've reached out to a few few people. So we'll we'll we'll
[01:07:02] Thomas Graf: keep doing that. Thank you.
[01:07:13] Benoit Claise: Alright. So quick transport for network telemetry.
[01:07:18] Joe Clark: Can you please put a timer? Super.
[01:07:22] Benoit Claise: So the problem is that we have a couple of protocols, management protocols, that are UDP based. Right? It's not a problem, but because we accept to lose a lot of packets. Typically, yang push d p notice or syslog or radius or ipfix. So the scope of this document is about push telemetry for management and data plane. So the issue as well is that we have fragmented certificate management, one per protocol. And depending no mandatory transport security, there is nothing for Syslog. There's IPfix, DTLS is optional. Yang push VP Notef, DTLS is optional. And sometime weak authentication with, Radius. So the idea is to say, can we reuse QUIC to solve that issue and carry all these UDP based protocol into QUIC? That would be that would reuse, obviously, t l s one dot three, which is combined with QUIC. We would have in there two bytes to demultiplex the type of telemetry per protocol. And in this case, because QUIC could be initiated from both side, in this case, we say the scope is router initiated telemetry. In QUIC, you've got the datagram frames or the stream frames. So what about we use the datagram, you know, for all these things like sending flow records? If we lose one, it's not the end of the world. But we would inherit from QUIC authentication, encryption, integrity, congestion control, if it's important, and the connection ID for the connection migration. I'll come back to that. So the example, IPfix data record syslog. Now in case we have a couple of telemetry messages that are important, to be reliable, we could also think of that IPfix templates, yank push and change, those are quite important to be send reliably. And the last slide, so I want to get discussions, is what would be the advantages? First of all, we have a unique node ID. Because right now, this is seen from a collector. It's the IP address of the source packets. So the outgoing interface of the the router. And this connection ID would survive a failover failover of the interface. Right? So we still have the same unique ID as you were mentioning in one of the previous presentation. So the connection migration without re authentication, thanks to the connection ID from from QUIC, a single connection for instead of all these DTLS ones, a single certificate life cycle, enhanced security coming from tls1.three, and there is even a way to describe, how to do Anycast, which is sometime interesting whenever you want to send to multiple collectors by a single IP address. So that's where I'm going to stop to get discussion. I see people on the line.
[01:10:56] James Cumming: Sir, James coming. Knock here. I if I thought I heard you right, and when you said you were gonna restrict this to dialing out. Was that right? And and if so, what was the reasoning for that rather than doing it for both?
[01:11:09] Benoit Claise: Because there are a lot of thing something over quick. And in there, we wanted to just focus on the telemetry part. It's just a question of scope. In the end, there is nothing that prevents you to say it's going to be initiated from the collector.
[01:11:25] James Cumming: Okay. Fair enough. Yeah. Because dial in telemetry is pretty common as well.
[01:11:31] Benoit Claise: I don't disagree. I mean, we didn't want to be like management foo protocol over QUIC and say, we're going to do Nnetconf and BMP and everything because there are already a lot of documents and maybe they serve a purpose and maybe just for telemetry in dial out, there is something to be done.
[01:11:49] Jeff Haas: Jeff, and you're heading to the point I wanted to hit. My work in Quake is still mostly academic. One of the bits of warning we've been given is the token management for the individual streams means that you have to be very careful exactly how you're pushing stuff based on what the receivers are capable of doing. Many of your use cases here are, you know, potentially high speed, like IP fix. So if you start putting everything over the same connection, think I you're gonna run into some interesting flow control issues. This is something that the quick working group will have opinions about. Please ask about it. Thank you.
[01:12:23] Joe Clark: And we are close to time. So if you have comments, please keep them very, very brief.
[01:12:31] Per Andersson: Thanks for its work. Is it me in queue or you, Rob? Okay. So I'm thinking of the definitions needed for the UDP note if, for instance. Is it underspecified in this draft for yang push? Because you need to be able to put where the receiver is and so on in the in the subscriptions container, for instance. Does this go in here, or is that some other work? Because now it will just say UDP Note Tip for this if you reuse UDP Note Tip, and that might be necessary and good to know if it's actually actually quick.
[01:13:03] Benoit Claise: We will need to have that or it's going to be, I'm not sure yet.
[01:13:09] Rob Wilton: To compress my comments down, this is good work. Carry on. I'll give you some comments on the list.
[01:13:23] Qin Wu: Actually, you still have another slide? Yeah. You you defined the telemetry header extension. It seems like a quick extension. Right? So I think this maybe requires some review from WIT area or some
[01:13:39] Benoit Claise: Of course.
[01:13:40] Qin Wu: Okay.
[01:13:40] Benoit Claise: And there is session from Per in the ops area, and it's also discussing the WIT open area, not especially this draft, but management over QUIC.
[01:13:50] Qin Wu: Okay.
[01:14:08] Yunsong Liu: Hello, everyone. I'm Yunsong Liu, China Mobile. I will present the export of beer information in EpiFix on behalf of my courses. BEAR is a innovative multicast forwarding architecture, so it's not to require explicit attributing protocols and and not need to maintain the per flow state. So it has own specific packet header. So the existing IPFIX IEs cannot export the data the the the flow parameters. So this draft will define the dedicated by beer EpiFix IEs. Last ITIF, we have the presentation at the peer working group, and we have received the positive feedback. So we we removed the BIFT ID. So because the BIFT ID indicated the the local a routing table, but we the it's it's it's a low level low low value for for this for this draft. And so we added three new elements, s d, s I, and the incap type. So we have defined the 12 new IP fix IEs to the the beer information element. So the new IEs can answer the questions like this. For example, the is this this packet a beer packet? What the type and the what are the SD and SI and the payload or the BFER? That means the destination of the beer packet. So first part of the I is for for the beer forwarding, including the beer SDSI and the in cap type, and also the the the impart important field for the bitstream. Bitstream means that together with the ICSI, it can identify all the destination BFER that all the receivers. And the next one is the b f I BFIR ID. That's a ingress router of beer and a TTL for the beer. The second part is the packet contact IE, including the next next protocol and the version and the base stream lens. The third part is the additional handling and the OEM information elements and the including the entropy. Entropy for used by the load balance for the beer packet and the DSCP for the queues and also the OEM for the embed OEM function. So we seek for the modern feedback from the working group and welcome the involvement in this proposal. Thank you. That's all.
[01:17:30] Joe Clark: No comments? Thank you.
[01:17:35] Yunsong Liu: Yeah. For the next option.
[01:17:38] Joe Clark: So this is the BR one. Right? Yeah.
[01:17:41] Benoit Claise: You mentioned that you received good feedback from the BR working group. Right?
[01:17:44] Yunsong Liu: Yeah. Yeah. Yeah. We we have a present in the BR working working group.
[01:17:49] Benoit Claise: So this is typically one of those documents where I was thinking in the beginning. Okay. This is IPfix. But if you receive pretty good feedback from the peer working group I mean, IPfix has been there for for many, many years. Feel free to go to that working group. It doesn't mean that we are pushing you out of the working group, but where do you get the most feedback? If it's in that place, request it there, the the the call for adoption. And maybe that's something that we want to do along with Mahesh and send this to the beer work group chairs and agree between the eighties on what we do here. Because I I foresee we're going to have more and more of those drafts that are, you know, technically specific, but done here because we used to do it.
[01:18:34] Yunsong Liu: Okay. The second of my presentation is about the export of beer POV in epi fix. Oh, r c sixty eight eleven defines BGP POV mechanisms. So the purpose of this draft, we define the the epi fix IEs of of this mechanism. So this draft can address the gap in the current IETF standards to monitor the PoE. And it's going only and also can enhance the network observer ability by the transform the local validation state of the BP routes into the epi fix date. And also enable the operators to detect the potential root hijacks and improve the network security. This is the definition of the epics IE of the BGP PoE. Enabled as a BGP prefix origin validation state, and the value is is defined by a unsigned integer. Zero zero means that valid and one means not found and the two means invalid. And it aligns with the RRC eighty ninety seven. We have some good discussion in The Middle East and have some valuable feedback. And firstly, we thank for the Jeff for the comments on the IE designs. For the one one for one one of this draft, we update the modify the the IE description with the reference to the definition to in r c eighty ninety seven and changed the date format for the unsigned integer rather than a bit vector and added a reference to the RFC eighty eight ninety three to color clarify the IE the information expected by the IE is the result of of the this API application policy and added the deployment considerations for the scenarios where the BGP POV validation function is not enabled or the router is the root is nonactive. So, secondly, we thank for to the for the comments on relationship with the existing IEs. So for the chapter one, update the for the validation state. We mean update the validation state is obtained by the comparing the BGP update prefix or AS with the local RPK VIP cache, then the exported to the IP fix collector. So the valid BGP ROS corresponding to traffic flows. So the the exported BGP POV validation state serves as a a root validity attribute for the corresponding BGP flows. So our draft focus on the comparison or the verification between the local BGP PoV and the RPKI, which is distinct from the issues addressed by the ID existing ID of the 200And94. The third the third layer is that thanks to the high end, Jeff, for the scope clarification. And for the version two, we add the clarification. The IE is scoped to the look array simply because the IP fix exporter typically monitor the installed forwarding state. So for the inactive routes, backup routes, and the routes not selected outside of scope of the disrupt. So welcome. More reviews, comments, and questions. So we, co authors, think that the the draft has a a very good discussion, and we would like to request a working group adoption. Thank you.
[01:23:03] Benoit Claise: Any feedback on this one?
[01:23:07] Joe Clark: Paul?
[01:23:09] Benoit Claise: Oh, Paul.
[01:23:11] Paul Aitken: Benoit, this is a comment to the chair to you. I would prefer personally if the IPfix documents would remain in this working group because it's one place to track them rather than having maybe lots of drafts across different working groups makes it a bit more tricky to follow what's going on.
[01:23:33] Benoit Claise: And Paul, you speak from a pure interest point of view or like an IP fixed designated expert?
[01:23:41] Paul Aitken: Maybe both, but if one person is trying to track is trying to see what's going on there, You're following documents across the whole of the ICF. That's a bit tricky. So, yes, it's personal motivation. Yes.
[01:23:59] Benoit Claise: Alright. Because I was about to say that I gave the example of beer before, which is in different area. In this case, you've got to grow working group, Mr. Paolo. And checking at charter, it's monitoring as well, right? So you do BMP, you do Yang. I mean, how far are you from IPFix? So okay, we'll discuss with the ADs on what to do on all these. I understand Paul from a just pure IPfix interest, it might be easier to have it here. But regardless, there will be communication with this working group on IPfix-eted documents, at least that's the way that I I force you this even if it's done a different working group.
[01:24:37] Paul Aitken: Sure. So I would say only that the what's the purpose of the draft? It's to request some new information elements. Right?
[01:24:49] Benoit Claise: The purpose of the draft is just to request IP fixed information elements? The purpose of the draft is just to request IP fixed information elements?
[01:25:02] Yunsong Liu: Yes.
[01:25:04] Benoit Claise: The answer is yes, Paul. And your point on this is that maybe a draft is not needed. Is this your point?
[01:25:10] Paul Aitken: No, but only that it's within the remit of this group to do that. Am I wrong?
[01:25:20] Benoit Claise: I didn't get that.
[01:25:21] Joe Clark: So so Paul Paul saying it's in the remit of opsawg to do that. It it it is, but I I also look at this akin to, like, yang, and not all yang modules go through NetMod. There are ways to rope in experts, for IP fix like yourself, that you don't necessarily have to follow everything directly. It would be incumbent on chairs in these other working groups to seek out the experts to provide the IP fix. The the question that Benoit and I have is, would you get better review, substantive review on the underlying technology and how IP fix interacts with that in those individual working groups versus always coming to opsawg. And we want we want the best technology, the best solutions to go forward, and that's why we were suggesting maybe some of these could be done, in those more technology specific working groups.
[01:26:17] Paul Aitken: Okay. Thanks.
[01:26:19] Rob Wilton: K. Rob Wilton. So not not comment on this draft in particular, on this discussion about where to do the work for IP fix. I know that I come to opsawg. I'm interested in half the work, and the IP fix stuff, I'm not actually that interested in. And, again, in terms of reviews and things, I think that you either need to move IP fix, as you say, out to other working groups, or maybe you do it, you split the sessions and do one session on non IP fix and one IP fix and different people come. Does it help with the reviews? Or maybe, Mahesh, it's worth spinning up an IP fix maintenance working group. But so the experts will be able to to work on that and go to that one. But at the moment, I feel that it is a bit heavy on Opsawg to have so much IPfix stuff maybe, but it's not my issue.
[01:26:59] Benoit Claise: If I understand you, you want to have, like, a virtual IPfix meeting that you don't attend. Right?
[01:27:04] Rob Wilton: Exactly.
[01:27:08] Jeff Haas: Jeff has, again, to the discussion rather than to the draft. Picking an IDR for this draft, the expertise in IDR is about the routing. This is taking a forwarding state and decorating with routing data. A number of the IP fixed no use cases are going to be this is how we actually talk about the forwarding. And that's not necessarily what the core working groups you're going to be talking to need to do. They're just simply providing supplementary data. So this doesn't fit really in either home. Here, we have the expertise about how the, you know, IPFIX works. I agree. You don't want to make this the only agenda item. Find a way to split it. No. This is something that can probably go off to interims. But in terms of cross review, again, this has been presented, I believe, in IDR at least once. And, no, they are getting, you know, the review that's appropriate for it, but the majority of the review is very small. They're representing the states correctly. The rest of it's encoding.
[01:28:08] Benoit Claise: Final words?
[01:28:10] Mahesh Jethandani: Mahesh, again, not as Rob said, not particularly this particular document, but in general about the ability to make sure that all is getting flagged on every IP fixed document. My understanding was that the it gets captured as part of expert review during I don't know what stage. I wanna say working group last call. I know picks it up or and flags it that there's an expert review required at which point Paul has sent a pointer to say, do the review. It doesn't matter which working group it comes from. But maybe I I'm wrong. And if that process is missing, that certainly can be added.
[01:28:56] Benoit Claise: The thing is that Paul have been more active specifically with his friend Claude lately to provide feedback on the mailing list and somehow this is good as well. So I understand his point of view as well. So we'll take it offline and the ADs are going to decide, I guess.
[01:29:11] Greg Mirsky: So I just want to mention when we're talking about what working group to do. And if you look at BFD, for for example, the core BFD stuff is in BFD. There's not much more of that going on. But all the BFD over x, over Geneva, whatever, they occur in the specific working group and not in BFD. So for me, something like that, if it's beer, it makes sense that it would be in beer as an example. Thank you. But we review. Yes.
[01:29:38] Shunwan Zhuang: Thank you. Thank you. Thank you.
[01:29:43] Joe Clark: I think it's you again. Yeah.
[01:29:48] Benoit Claise: Talking about IPfix. Order IPfix order information element export IPfix. So I'm going to be quick to give a couple of references and more time for discussion and save time in the end. So we've got metering process on the left. They create flow records. Then the exporting process export the IPfix messages, and the collecting process is trying to make sense out of the data. The issue is that sometimes we've got multiple instances of the same IPfix information elements. So what do we do in those cases? MPLS, SRV six, destination IP address. On the right hand side, the collector cannot deduce what has been done on the router because on the router, it says on the left that you should follow the logical order of the treatment. It's a should. How does the collector know it was suspected or not? It doesn't. There are no ordering signal. There are multiple use cases. On this slide, I just want to show one point. It's valid for template records and options template records like the last PSAM tell you there that PSAM, there is a must. It must be in the application order whenever you've got multiple selector IDs, filtering, hashing, etcetera. But pSam is based on IPfix, which has a should. So it's it's like, yeah, there is something to be to be done there. So how do we communicate from the router to the collector that the order was respecting along the tool chain? We have two new set IDs, four and five in red there, for ordered template and order options template. This is the explicit message coming from the router to the collector. And this document, as a consequence, updates multiple specification. First, the one from IPfix, because the metering process must record the repeated information in the right order. The exporting process must preserve this, and the collecting process must interpret this that way. So must must must along the tool chain. Now in the case of PSAMP, there's an update because the PSAMP spec should be you I mean, must be using the new set IDs. Otherwise, you don't signal it. And finally, if you got the mediation box, mission function, a mediator, at the end, you must preserve the order if you receive in the right order. So last slide and feedback so far. This is a real problem, and we knew it because we had one draft in the past about multiple instances of information elements. Joe has got a proposal to split this into two parts, the functional part and the IP fixed information element. It makes sense. Joe, very good point that it's not an opt in as mentioned because even for PSAN, it's a must. We must be changing the specification. Paolo has two interesting points telling, in some situation, if I take an MPLS set of labels, how many do we have? We don't know. So maybe in that case, instead of telling I've got one template with one, one template with two, one template with three, let's have a list. How do we signal this? By telling it's an ordered basic list. Specifically, it's a new data type. And he's telling, you know, you're solving the ordering issue, but, actually, sometime, you're exporting the m p s label one, the top one, and the third one. How do you know that on the collecting process, it was not one and two? So it's a small addition to say there's a position in there. Whenever it's received at the collector side, you see the first value is blah, this third one is blah, and two is empty. So it's a potential problem to be solved, and this is where I stop. Any feedback on this one? Paul, I believe you're in the queue, but from the previous one. Right?
[01:34:06] Paul Aitken: Sorry. Yeah. So then into the.
[01:34:15] Benoit Claise: Thank you.
[01:34:39] Joe Clark: Okay.
[01:34:46] Yali Wang: Hi, everyone. It's from ZTE. I'm presenting the draft as part of using information in IPfix. Because we have presented during last meeting and to off CWG and the TSVWG And considering the time is limited at this time, so I will mainly introduce the updates in this draft. After last meeting, we have received some comments from Benoit and Gorry. It's related about, you know, why you use a dedicated IPCN node to reuse existing IP class of service. So in this draft, we address it. And also received comments from the head, which is about privacy consideration, and we also received some comments from Paul. So we have adjusted the comments. And about the main updates in this version, First one is about we merged the IPUA four header eastern and the IPUA six header eastern to a single IPUC and the information element, which is we consider a it is, you know, to align with existing IP class of service and IP diff serve code point, which is protocol agnostic. And we also added some limitations of yield reusing the existing IP class of service. If we reuse existing information element, yes, it can export the eight base of the SAP ID SIN and then export the last two base of sorry. The eight eight eight base of tolls or IP based sys traffic failed information and then export the last two base of ECN information. But it you know, it's technically feasible, but may also bring some limitations such as one in a large scale alpha is deployment. The same ECN field may have different d DSCP field or DSCP values, which will bring to, you know, many different flows record, such as Atmos two sixty four flow recall. So it will bring more big complexity. So the scale matters about NPL's eastern information element. There's also an existing NPL's top label ESP field, but this information element is managed to export the generic ESP field in MPs label entry. And we create a new MPs using information element. It's mainly to consider to expose the information. So they are very different in semantic. And in this draft version,
[01:38:21] Joe Clark: we
[01:38:22] Yali Wang: add a new information element, which is about to expose the e ECN information in MPLs MNA on networks. You know, it use the MNA opcode to carry ESA information, which has no dependency with ESP because ESP needs to carry both traffic class information that also, you know, carries the ESA information. So to support this semantic support this encapsulation m p s m a. So we under this information element. So next steps, welcome your review and feedback, and we also would like to seek more co authors on this draft. Thank you.
[01:39:31] Benoit Claise: Any feedback on the draft? Thank you.
[01:39:58] Shunwan Zhuang: This is from s three c. This draft is about export segment routing policy attribute in IPfix. So the background currently segment routing policy is key for t or SLA, And list knows standardized method to color rate and observe the IP traffic flow with a specific ASR policy. So this draft is to define the new IP fix element to export as a policy attribute. It allows exporting process to tackle flow record will apply as a policy. In this document, we define the four new IP fix I I e information elements. The the first element, as a policy hand head and address. And the second, the color of is our policy. The third the end part of is our policy. The fourth, IE's, the forwarding type of is our policy such as SM or SR v six. In IP fix message example in the following pictures, we can see when we report a five couple such as source address, test, and the protocol source port and test port. Then we can also report the four new defined IEs such as policy head end, color policy end part, and policy forwarding type. Use this. We can call call relate IP flow and the s r policy. Maybe we we can export the s r and the IP flow. But in the complex the scenarios, we we may have no as such headers. And also, as such, that's not identified in the as a policy. So we define the as a policy to correlate flow record. The key use case as the following for SLA relocation or troubleshooting or t service monitoring. The operational can slate for the new IEs. We it can report it in the head end node, and it just complement for the existing flow IEs. That's all. Any question comes are welcome.
[01:43:16] Joe Clark: Thank you. Yeah.
[01:43:30] Shunwan Zhuang: This is a nano draft export QUIC information in IP fix. So the background, QUIC is UDP based just just part of protocol and is widely used in network. So it's but how to collect quicker information in forwarding traffic traffic is not defined. So this document proposed the exporting quick information by extending IP fix. In this document, we defined seven information element to export the quick information. Quick had the flag, quick version, quick test connection ID, quick source connection ID, and quick packet number, quick frame type, also the quicker string ID. The update of this draft, it was presented at ITF one hundred twenty two and one hundred twenty four. The comments from and we updated the draft from version three to version four. The first update, we add clarification letter return flow in this document to align with the artifacts that that's. The second update, we enhance the discoloration or pack the discarding monitoring line will it will standardize the discarding reporting framework. The third update will redefine the language and describe how quick information is associated with IPfix flow records for both quick long and the sub header packages. We also add the new co author, This draft is stable. So we coauthors would like to ask for adoption call. Thanks.
[01:45:58] Benoit Claise: So can you go back to do I have people in the queue first? No. No. Okay. Can you go back? Okay. Seven information elements.
[01:46:08] Giuseppe Fioccola: Yeah.
[01:46:09] Benoit Claise: So you define something about the use cases in your draft. Right? The different use cases in the section where use case. Yeah. Do you reuse all of these seven in the use cases?
[01:46:26] Shunwan Zhuang: Yes. In it can be two different packet, the long packet and then the short packet, which will use different information elements.
[01:46:43] Benoit Claise: Okay. So in the use cases you're defining in this section, you are using all of these seven in in the the use cases. Right? Yes. Okay. Thank you. I want to check that.
[01:46:56] Mahesh Jethandani: It syncs.
[01:46:58] Benoit Claise: So this draft has been put in multiple times. There were feedback in previously. We would like to to understand if there is some interest in the working group to adopt this. So do you want to run a poll now? Oh, it's there already. Okay. I'm always interested whenever someone says no. We don't want to do it. No.
[01:47:50] Joe Clark: They just removed themselves.
[01:47:52] Benoit Claise: Alright. Problem solved. Okay.
[01:47:59] Joe Clark: I think we can there's some obviously, 91, we'd like to see more, but I think we can run-in a poll on the list adoption on the list on this. Thank you.
[01:48:09] Benoit Claise: Yeah. Thanks.
[01:48:27] Lancheng Qin: Good afternoon. Thanks for the chairs and to giving me this opportunity to present our draft export of source address validation information in IPfix. So another IPfix draft. Today, I'll I will mainly go through the updates of the draft. Before that, I'm going to give a brief preview of the draft as idea. So the problem we encounter is that sub lacks operational visibility. And just to address this problem, we designed new IP fixed information elements to export the context. The elements are listed below, and they cover the sub the general sub modes applied in the network, the specific sub rule contents, and the sub policy actions that is adopted in the data plan. So we in this new version, we mainly made three core updates, which are all textual updates. So no design changes for the elements are made. These textual updates is to is to clarify the scope of the draft in three ways, what we monitor, what we report, and how we specify. I will go through these in details in the following slides. So the first update is about terminology. In version one, we use the self effectiveness monitoring. The problem of effectiveness is that it implies that we evaluate how SAF works, whether SAF was actually enabled, what the false positive or negative negative rates are. But this is a bigger question which IPfix cannot answer. So in version two, we revised it into staff enforcement monitoring. To clarify this, the draft only observe and report what happened. So the effectiveness the effectiveness to enforcement, this is the first change. And the second change is closely related to the first one. So we in version one, some sentences were written as if we already made a claim that the packets is definitely spoofed. This is a assertion of ground truth, but IPfix does not assert any ground truth. It only report what was observed. So we we revised the language in version two to clarify the scope that IPfix only report what it was observed. And the the third update is about flexibility. In version one, we specify we described a way to associate soft data records with packet level details using an element called selection sequence ID. But we realized that this is implementation details. We should not prescribe any association associate method previously, we should leave the flexibility to the implementers. So we revised we removed the association method in version two to leave the flexibility to the implementers to choose their own approach. So this is the third change. So to summarize the three updates, we changed the term we changed the term effectiveness to enforcement, and we changed the language of searching any ground truth to reporting observations only, and we removed some specific implementations. So the next step of the this draft would be we would like to call for a group working adoption. Any questions or discussions are welcome.
[01:53:29] Joe Clark: Sorry, Jeff. Can you take it to the list? We are way out of time because we still have two more presentations. So thanks, Jeff. We will discuss adoption on list. In one, I will discuss it.
[01:53:41] Lancheng Qin: Okay. Thank you.
[01:53:45] Joe Clark: Yes. And we have two more presentations. We're hoping, yeah, you can be quick, and we can get through both of them in record time.
[01:53:56] Yali Wang: Okay. I'll be quick. The last IPfix document, I'm from ZT on BGP VP information. So this draft defines four new IPv6 informat information elements for monitoring BGP VPN traffic flows, especially for pretending the egress piece information. The first two element is generic information elements for BGP VPN NextHope IP address. And especially for SRV six VPN traffics, and the third and the fourth information element are defined. So you can choose what to use for SRV six VPN. So it has been presented in OPSawg and BEST last ATF. So the comments we get from BEST from Stefan is what's the relationship between the generic BGP NextHope IP address and the new BGP VPN NextHope IP address. So how to operate between them? So it should be explained. The updates in the next slide. And comments is why not obtain the egress IP information from the network controller, which configures a VPN rather than via IP fix from the the device. So the answer is the first controller based lookup requires different rules to drive the egress p based on various VPN configuration policies. So and the second is AbiFix serves as an independent data plan verification, which is essential for detecting control plan versus data plan differences. And also, thanks to Thomas' comments to say that this seems workable. And about the updates. So the first, we have a more precise definition of the BGP VPN Nextel address. So now it's a now it represents the IP IP next hop address of the matched BGP VPN route. For example, from the corresponding entry in the VPN specific BGN routing formation base or the app table. And about the operational considerations of the generic BGP NextHope and the VPN specific BGP VPN NextHope. And for VPN flows, you should use the VPN specific information elements rather than the generic generic ones. So exporting both of them at the same time is not recommended to avoid semantic overlap. And if both appear in the record, collector should prioritize the VPN specific IEs as
[01:56:49] Yali Wang: they
[01:56:49] Yali Wang: are more precise. And if only the generic information element is present, its routing context, for example, whether it's BGP Unicast Next Hub or BGP VPN Next Hub cannot be determined from the information element alone, so you may need extra information. And oh, thanks for post review. And we've update just update a new version. So we'll come further feedback and comments, and we'll find it. And we it's pending implementation, not all of them all of them, but about the s r v six VPN part. And we request to consider to with the working group to consider adoption maybe after your working group's decision where it belongs to.
[01:57:37] Joe Clark: So even though we ran one poll, Benoit and I will discuss with the chairs for all of the IPfix documents that requested adoption, we'll discuss where that adoption should occur. So we we will handle the asks for adoption calls. Thanks. Last presentation. I'm sorry for the timing, the way it worked out. As as quick as you can get to the salient points, that would be much appreciated. Thank you.
[01:58:07] Jing Zhao: Hi, everyone. I will quickly I'm Jing Zhao from China Unicom. I will quickly introduce our draft problem statement for network resilience. First, I will explain why network resilience is needed because the traditional reliability mechanisms may address predefined and relatively isolated failures. For example, link and node protection, factory router, and the recall regions. But, however, operational insistent increasing involve, correlate, and the cascoding failures, config configuration and policy errors. This exist a resilience gap. The network should not only recover from the known failures. It should be able to anticipate, detect, content, adapt, and learn. So in this slide, we list where the resilience instant comes from. The failure sources involved the physical infrastructure failures, confrontation and operational errors, network planning and design defect, control plan and practical anomalies, grid and partial degradation, and the security incident. And one incident may involve the several failure sources at the same time. So we in this slide, we list the cross coding challenges. For example, the correlated and the cascoding failures, resource existence, and the loss of the carry capabilities and the the recovery systems reliability. So in here, we can see a life cycle value of view of network failures. So we think the network resilience need to cover pre event, in event, and post event, the three stages. And based on the life cycle, we see we here, we summarize the key capabilities for network resilience. Resilience is not able about faster recovery. It require the network to anticipate, content, adapt, and learn from complex failures, like the risk awareness validation, resource aware protection coordinate the fear continent. And here, we show scenarios that local failures become a large scale affairs. And the next step, we want to define resilience, capabilities, and the requirement for one or more network domains and explore protocol and mechanisms enhancements, develop best current practices for resilience enhancement, and the below is the related draft about practices. That's all. Thank you.
[02:01:40] Joe Clark: Thanks, Jing. We're out of time, but I do have comments. I will send them to the list. So thank you for this. Look for an email from me soon. Thank you, and thanks all to opsawg participants. As I mentioned, we will consider all the calls for adoption that have been asked. We'll discuss the IP fix with our ADs to find the right places for them. And we hope you have a rest great, rest of the year. IETf-one hundred twenty six is fantastic.
[02:02:09] Qin Wu: Thank you.