Minutes IETF99: opsawg
minutes-99-opsawg-01

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.

==================================================================