* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Opsawg Status Pages

Operations and Management Area Working Group (Active WG)
Ops Area: Benoit Claise, Warren Kumari | 2007-Jun-13 —  
Chairs
 
 
 


IETF-99 opsawg minutes

Session 2017-07-18 1330-1530: Congress Hall III - Audio stream - opsawg chatroom

Minutes

minutes-99-opsawg-01 minutes



          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.
          
          ==================================================================
          
          



Generated from PyHt script /wg/opsawg/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -