What: Joint OPS Area and OPSAWG Meeting When: 13:30-15:30 Tuesday Afternoon session I Where: Congress Hall III OPS Area Section --------------------- 1. Administrivia - scribes, minutes, etc. Benoit / Warren 5 minutes Wes Hardaker agreed to take notes, and Joel Jaeggli agreed to be the Jabber scribe. NOTE: The Note Well has changed. It now mention that contributions are subject to RFC8179 (in addition to RFC5378), which spells out legal verbiage around IPR disclosure. Everyone should review this. ================================================================== 2. yangcatalog.org development Slides: https://www.ietf.org/proceedings/99/slides/slides-99-opsawg-yang-catalog-00.pdf Joe Clarke 15 minutes Draft describing backing store for YANG metadata: - https://datatracker.ietf.org/doc/draft-clacla-netmod-model-catalog-00 - Catalog tools available at https://yangcatalog.org - Accumulating open tools - Wes Hardaker: who is "we" when you say "we" stood it up + Joe and Benoit have done this + Now soliciting vendors to help volunteer to run it - Kent Watson: I like where this is going; I look forward to translators and converters too. - Andy Bierman: Still not seeing the higher level organization, at one point called "yang packages". The granularity is only going to get worse. Referenced another packaging system that releases a whole collection of specs that are known to work together. We might do something like that with, for example, "routing". People don't want to look at 120,000 modules. OpenEmbed is doing a good job taking a problem 3x harder than this, and adding layers, etc to make it manageable. + Joe: We discussed doing that, and it's down the road + Joe: Even want to potentially build a debian package, or ... + Joe: I liked the idea of bundling things that work well together - Andy: I was on the MIB police for many years, and the biggest problem was getting people to reuse + Joe: I understand that; I worked on SNMP for 19 years at CISCO + Joe: We definitely want this too + Benoit: another way to look at a bundle is a 3-tie(?). The Hackathons is a great place to come work on this, but we're working on it the rest of the time too. We will be there during bits and bytes to show more details. ================================================================== 3. How the IETF needs to evolve Benoit Claise (and Richard Barnes) Semantic Versioning and Structure for IETF Specifications https://datatracker.ietf.org/doc/draft-claise-semver/ Slides: https://www.ietf.org/proceedings/99/slides/slides-99-opsawg-semantic-versioning-01.pdf 15 minutes - (mixed discussion on yang models and the process of producing drafts with yang models as the world changes to move faster than the IETF) - Dean Bogdanovic: usually people don't implement until there is an rfc. with yang we're writing software, until you implement it we don't know if there is a bug. We believe in working code and running consensus, but the working code has been forgotten. - Benoit: I also want the yang modules to be easily accessible - I don't think it's an issue with what tools you can use. I think it's managers that say they don't want to do it until it's a standard. - For many drafts, e.g. routing, it was 6 years in the draft status. How many implemented that RFC? - Benoit: one of the ideas with the catalog is to give a score card... it compiled, included so many times, ... The score care will be what counts in the end ; if it shows a lot of use, then it becomes the de-facto standard - we also need a list of vendors that implemented a model - Phil Shafer: one of the nice things we've done in Junos is to make it so the modules can be converted to native data . We can take modules that have very early implementation, take the yang into a loaded VM and see that it represents data accurately and can be translated. - Andy Bierman: our review process discourages people from implementing early. Once it gets to the AD and the IESG, they can change anything they want. That's a significant problem. Another significant problem is that we don't know how to use augment yet. We keep piling on instead of shipping a core set of modules. If we had bundles, like I was talking about, we'd have a way to pull it all back together. - I have a solution to that: my former [awko] draft suggests creating a high level model for defining what we're looking for. Add the technical elements later through augments. But the WG disagrees and wants to but the technical pieces up front. A high level first module would let people implement it early. - Kent Watsen: sometimes the structure has to be augmentable. Much of the time, the later changes can affect the structure. - Richard Barnes: plan to use github to develop things - raise hand if ID is the preferred format for writing modules or code? (zero hands) - let's edit the things we directly care about with maybe some side-text. Let's do that and call WG LC on that - we can't do exactly that (draft-claise-semver), but we wrote up a document for how to write up a document for a standard document as an alternative format - How do we do semantic versioning too? - Define a repo for each module, which will define the history for a document and using tags to highlight the versions. Adopt a major/minor version number. Can fix bugs without a ietf document for minor changes. Major changes will still require RFCs. Replace internet drafts with feature changes. - Andy: you're aware that the yang update rules don't apply to a work in progress? we make changes to modules in drafts all the time. How do we know that "this work in progress" is ok to use? This semantic versioning only applies to published versions. - Richard: some of the publish process will be in the official version process - One interesting comment made during the wg: we might need to release an official version in november, but should last call it now so it'll be done - Eliot Lear: what's the process difference between a minor and a major change? - envisioned loser to existing processes - errata like approval for patches - minor updates may require a new RFC like process - Eliot: Where will the repository be? github? - We have no requirements in the document about here to host things. There is some work already started on that. - Eliot: I think this is all useful. - Some tools will be needed to bundle stuff into an ID, since that's what IESG expects - Phil: need more than tags, because we need branching too to support cross-patching across versions - Phil: when I did the original netconf draft, we used 50-80% used a tool that takes text that turns it into fancy stuff. - Phil: base modules and version numbers is key, as per Andy said. Base module is now version 15 or 16 and is supposed to be the most simple. - catalog should have the average age not published yet - Lee Howard: We need to keep track of what might need to be updating. Using git as a discussion platform is what I think the interesting point is here. Github doesn't support IPv6. ================================================================== 4. Open Mic No time left for open mic. ================================================================== OPSAWG Section -------------------- 1. Administrivia - scribes, minutes, welcome new chair, etc. Ignas / Tianran / Joe 10 minutes Joe Clarke introduced himself as a new co-chair. Joe is from Cisco. ================================================================== 2. Manufacturer Usage Description Specification Eliot Lear Draft: https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/ Slides: https://www.ietf.org/proceedings/99/slides/slides-99-opsawg-manufacturer-usage-description-specification-00.pdf 10 minutes While Eliot has a new revision forthcoming, he strongly requests people review the extensibility components now. ================================================================== 3. Service Models Explained Qin Wu Draft: https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-explained/ Slides: https://www.ietf.org/proceedings/99/slides/slides-99-opsawg-service-models-explained-00.pdf 10 minutes - Joe Clarke: on edpn, I was originally confused when reading the draft but am fine with that figure being left as an augmentation. How much more text is needed before last call? - we think the draft is in good shape now. We just want to make sure no one is confused about the yang model relationship. - We'll move the last call discussion to the mailing list then; ok? - yes ================================================================== 4. Export BGP community information in IPFIX Zhenqiang Li Draft: https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-bgp-community/ https://datatracker.ietf.org/doc/draft-li-opsawg-ipfix-extended-message/ Slides: https://www.ietf.org/proceedings/99/slides/slides-99-opsawg-export-bgp-community-information-in-ipfix-00.pdf https://www.ietf.org/proceedings/99/slides/slides-99-opsawg-ipfix-extended-message-00.pdf 10 minutes - https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-bgp-community/ - https://datatracker.ietf.org/doc/draft-li-opsawg-ipfix-extended-message/ - Who has read both documents? - 5 or so - Who are operators who see a need to deploy? - 3 - I think you need to be consistent about the number of communities you see in actual deployment. In public, there is not a huge number of communities in use. In private deployments you may see larger numbers, however, but the IETF may not be the right place to deal with that - Ruediger Volk: I'm seeing questions. I think the question about what circumstances are implementations realistic. I think that's a scalability issue. I wonder if we've collected some comments addressing the feasibility of this from the implementer side. I would assume that some ideas about what configuration to limit, focus and filter the information that actually goes into this is probably really important. If I was thinking about using that information, I would go after that and say yes I have a filter that is relevant for getting the statistics here. But I have other communities that I would not want to use to make the scalability worse. - Am I right that we need a operational consideration section? - author: you're right that you should limit the communities you use in the filter. You can use only the communities you want in the template for IPFIX. We'll report the information you want according to the template. - I'm curious how many operators would be interested in where the route arrived from in the network. Who sees it as an application for business intelligence? - just 1 - It would be good if you socialize this with operations, not just in the IETF, and add an operational considerations section to the document. And ask about the need to have that main domains exported. === On extending the message link of IPFIX: - updates IPFIX spec to extend message length - I think it's ready to be adopted - to the wg; what's the need to extend IPFIX? Please speak up on the mailing list with use cases for that (and requirements for extending IPFIX) - In particular with respect to use cases, what large messages are needed, or what uses cases might require many small amounts of data to be packed into an IPFIX message that could push its size over 64K? ================================================================== 5. Requirements for Interactive Query with Dynamic Network Probes Haoyu Song Draft: https://datatracker.ietf.org/doc/draft-song-opsawg-dnp4iq/ Slides: https://www.ietf.org/proceedings/99/slides/slides-99-opsawg-requirements-for-interactive-query-with-dynamic-network-probes-00.pdf 10 minutes - It was asked who read the draft. About 10 hands went up. ================================================================== 6. YANG Data Model for NAT Mohamed Boucadair Draft: https://datatracker.ietf.org/doc/draft-sivakumar-yang-nat/ Slides: https://www.ietf.org/proceedings/99/slides/slides-99-opsawg-yang-data-model-for-nat-01.pdf 10 minutes - Lee Howard: since it supports nat64 does it support 464xlat? it would be useful to state that. Typo in the document: this document "does" make an assumption about how hosts are connected. - Mohamed Boucadair: should be talking about CLAT since NAT64 is already covered in the draft - Do you consider the server nat or the destination nat? - it's not in scope so far, but we're open to include it. - Mohamed asked for adoption, chairs replied this will be conducted on the list. ================================================================== 7. Extending YANG for events, actions, and finite state machine Nicola Sambo Draft: https://datatracker.ietf.org/doc/draft-sambo-opsawg-ccamp-supa-ext-yang-fsm/ Slides: https://www.ietf.org/proceedings/99/slides/slides-99-opsawg-extending-yang-for-events-actions-and-finite-state-machine-02.pdf 10 minutes - It seems like you've created something that could be generally useful, but have done so in a specific use case. Are you intending to be more specific or more general? - started from this use case because I work on optical networks. I agree, it is more generic. This is just one use case. - I find this work really interesting: I do find it more generic than just optical work. What I would like to see is to have this work done in a general manner. and then have technological specific extensions. - Nicola: We'd like to use the finite state machine to increase the level of programmability - Haoyu Song: what you propose is interesting ; one way to implement the dnp (see draft presented above). The net probe is just a finite state machine. If you can extend this work to more than just optical networks, that would be nice. ==================================================================