What: Combined OpsAWG / OpsArea When: November 20, 2020 12:00-14:00 (UTC+7) Friday Session I Where: Room 4 OpsAWG Section -------------------- Administrivia - scribes, minutes, etc. (And introduce Henk) Tianran / Joe / Henk 10 minutes - Henk joins us as co-chair and has, as he says, a small IoT background. We're happy to have him on board. Manufacturer Usage Description (MUD) (D)TLS Profiles for IoT Devices Tirumal Reddy Draft: https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-tls/ 10 minutes - Rob Wilton: was SEC DIR looped into this? - Tiru: yes, this was shared with tls@ beforehand, and these changes address their comments Update on VPN Common Module Med Boucadair Draft: https://datatracker.ietf.org/doc/draft-ietf-opsawg-vpn-common/ 5 minutes - Joe Clarke: Clarifying question: Did you mean WGLC, or did you mean comments during the adoption call. - Med: Yes, these were comments during the WG adoptional call. - Joe: There are few comments that this might be applicable to L2xM. I liked that, in that it is showing that it can be reused, but it seemed to get lost towards the end of the document. Perhaps having a slightly different structure might be helpful. Update on L3NM and L2NM Oscar González de Dios Draft: https://datatracker.ietf.org/doc/draft-ietf-opsawg-l3sm-l3nm/ https://datatracker.ietf.org/doc/draft-ietf-opsawg-l2nm/ 15 minutes - Rob Wilton (participant) - might be useful to include the full YANG tree output in the appendix. Would it be useful for readers? Worth considering? - Oscar: full tree was so long in terms of lines and in width - Rob: then if it's so far indented, then it might make sense to leave it out (can also be generated by tools if one wants it) - Med: spans so many pages and is not very readable; it will be hard to manually groom the trees - Rob: then probably okay not to include it; but perhaps include _instructions_ in the apppendix to generate it - Med: A lot of issues in L2NM; there is a risk on the L3NM work if the L2NM languishes; - Joe: Raise hands: How many people have read the latest versions of these documents? - 10 raised, 6 not raised, out of 56 - Joe: Raise hands: Should we do WGLC of L3NM independently if issues still exist after 110 on L2NM - 11 raised, 0 not raised, out of 56. - Joe: If there are still issues that you want consensus on, then please present the specific issues, or bring them to the WG alias. - Oscar: We need more feedback from experts on VPN. Perhaps present in BESS to get more eyes on it. - Joe: Yes, we can try and help get some more reviews from BESS. Finding and Using Geofeed Data Randy Bush Draft: https://datatracker.ietf.org/doc/draft-ymbk-opsawg-finding-geofeeds/ 10 minutes - Joe (quoting George from Jabber): - George Michaelson (from Jabber) - people don't understand that almost all economy assertions in whois (for numbers) are about the entity head office location, not the network of use (unless the records are more specific than the delegation record) - Randy's on the money with this draft. its a huge problem - Tom Hill (from Jabber) - It is a bit sad that the Internet having no borders, has had them backported into it. - OTOH, that was inevitable, and this is real pain that persists for many millions of people - George Michaelson (from Jabber) - RTT triangulation to a position only gets you so far. Large CDNs/Content-providers who peer in hundreds of locations, *for example* know your BGP/RTT position pretty well. They choose not to share. - self declaration equalizes for the realities here - (but yes, IPR region lock is evil) - George Michaelson (from Jabber) - There isn't much [more] to say. It's good work, and it would solve real-world problem. - Tom Hill (from Jabber) - +1 IP Flow Information Export (IPFIX) Information Elements Extension for Forwarding Exception Venkata Chaitanya Munukutla Draft: https://datatracker.ietf.org/doc/draft-mvmd-opsawg-ipfix-fwd-exceptions/ 10 minutes - Joe: It wasn't clear what the next hop ID would be? I suspect that would be very vendor specific. - Venkata: We will add an example of the next hop id in the next revision. - Zhenbin: I think this is a useful use case, since we know that there are forwarding errors. - Shivam: Coauthor. Typically the next hop is a FIB lookup. What happens if the drop happens internally before leaving on the egress interface? This field can contain other forwarding plane metadata. - Joe: Thanks, having a concrete example would be helpful. - Rudiger: [confused and nonapplicable suggestion - withdrawn] Network Monitoring For IGP Shuanglong Chen Draft: https://datatracker.ietf.org/doc/draft-gu-opsawg-network-monitoring-igp/ 10 minutes - Robin: Brought this work two years ago. Have now identified the use cases to export the IGP protocol data. Difficult to define the YANG model. Want to unify the IGP and BGP with a similar mechanism. - Joe: Haven't seen any discussion on OPSAWG list, please bring the questions there. It would good to also see answers from the previous time that this was brought. - Rob Wilton: Why do we want a new protocol vs. use what's already there; why define a new protocol vs. describe them in YANG; key is to understand the data you want to export and what doesn't work with the current protocols instead of going down the path of defining a new protocol - Robin: In this draft we propose reusing BMP for these requirements. In terms of the YANG model, we were not as experienced in how this can be done, so we're looking for more comments/advice on how best to do this. - Rob: Focus clearly on the data to export and that can illumincate the data to export; it may be you have both BMP extensions and YANG; consider using CBOR as a binary encoding or GPB A YANG Model for Network and VPN Service Performance Monitoring Bo Wu Draft: https://datatracker.ietf.org/doc/draft-www-opsawg-yang-vpn-service-pm/ 10 minutes Joe - I appreciate that the VPN core group has worked on this and iterated the work; however, I couldn't find any specific discussion about this work on-list. Please bring the points that have been raised and announce the work on-list so people can get a chance to read it. It will make it easier to call for adoption If Time Allows: --------------- SBOM Extension for MUD Eliot Lear Draft: https://tools.ietf.org/html/draft-lear-opsawg-mud-sbom-00 5 minutes - Henk - You mention additional extensions; and NIST was proposing ROLI(?) - Eliot Lear - Yes, we realize we have to coordinate inside and outside the IETF; and we're speaking with NIST - Joe - ACTION: we can call for adoption after IETF109 Ops-Area Section --------------------- Administrivia - scribes, minutes, etc. Warren / Rob 5 minutes Discuss IOTOPS Charter Warren / Rob 20 minutes - Toerless - Getting more TOI from the industry into these meetings - Toerless - Don't want to unnecessarily constrain things to what is IoT and what is not IoT (e.g., all devices that don't have a typical user interface like routers and switches which aren't traditionally IoT [but lifecycle management may be similar to traditional IoT use cases]) - Rob: yes, definitely desired to have TOIs come here; which is why we wanted a WG vs. a mailing list - Rob: we wanted to be a bit flexible in defining "IoT" (people will know it when they see it); we can rein things in if they are going out of scope - Warren: we've been trying to get this going for a while and we shouldn't let perfect be the enemy of good and start something up and see where it goes - Toerless - my point was just not to unnaturally draw lines based on loose terminology - Henk (from Erik Kline on Jabber) - does this blow up the IOT DIR? - Rob: no, this isn't designed to interfere with the directorate - Warren: yes, this is designed to be more complementary - Eliot: glad this is happening; charter text is good; it will befall the IESG and other groups to make sure that work at least gets socialized here even if the work is not done in this WG - Rob: sounds fine; makes sense - Rob: Thanks for the feedback; we'll try and get this up and running soon - Rob: Ops Ad office hours; Warren and I will be around for the next 30 minutes - Rob: Meeting closed Open Mic