Subject: [OPSAWG] Summary of OPS Area / OPSAWG from IETF 99

From: "Joe Clarke" <[email-masked]>
Date: Tue, 25 Jul 2017 11:19:39 -0400

Below are the minutes from the combined Ops Area / opsawg meeting that 
took place in Prague on July 18, 2017.

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 incorporates more 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 464cilat?  it
     would be useful to state that.  Typo in the document: this
     document "does" make an assumption about how hosts are connected.

- Do you consider the server nat or the destination nat?
     - it's not in scope so far, but we're open to include it.

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

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.

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

Joe Clarke (for the co-chairs)

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Jul 2017 08:26:39 +1200

> verbiage around IPR disclosure.  Everyone should review this.

The slide shown in the WG seems to be out of date compared to
https://www.ietf.org/about/note-well.html, but the substantive
changes aren't in the Note Well; they are in RFC8179.

More substantive:

>      anything they want.

If a reviewer or an IESG member suggests a substantive change,
that doesn't give *them* the right to change it - a substantive
change must be brought back to the WG. So the underlying problem
here is not about who has control but about the fact that
implementing on the run almost guarantees that your implementation
will be out of date when the thing is finalised. That really is
not specific to yang, or to the IETF, or to networking.

(In 1925, public electricity supply in London was at 24 different
voltages and 10 different frequencies. They didn't wait for the
standard to be final then, either.)

It seems to me that declaring snapshots from time to time is
about the best we can do, accompanied by a strong warning that
the final version will be different.

    Brian

---

From: Andy Bierman <[email-masked]>
Date: Tue, 25 Jul 2017 13:39:11 -0700

> not specific to yang, or to the IETF, or to networking.

The WG has a choice: change the draft if you want it to be published as an
RFC.
They are usually motivated to clear the DISCUSS.

> the final version will be different.

I am not suggesting the review process needs to be examined (again).
People are warned that a work-in-progress can change.

>     Brian

Andy

>
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>

---

From: Tianran Zhou <[email-masked]>
Date: Wed, 26 Jul 2017 02:55:02 +0000

Hi Brian,

Fortunately, we did not use the "chairs slides" finally in the meeting.
Instead, "OPS Area Administrativia" and "OPSAWG Administrativia" are used. Both of them included the latest Note Well.
Let's remove the "chairs slides" from the material.

Thanks,
Tianran

> -----Original Message-----
> From: OPSAWG [mailto:[email-masked]] On Behalf Of Brian E
> Carpenter
> Sent: Wednesday, July 26, 2017 4:27 AM
> To: Joe Clarke
> Cc: [email-masked]
> Subject: Re: [OPSAWG] Summary of OPS Area / OPSAWG from IETF 99
> 
> Nit:
> 
> https://www.ietf.org/about/note-well.html, but the substantive changes
> aren't in the Note Well; they are in RFC8179.
> 
> More substantive:
> 
> If a reviewer or an IESG member suggests a substantive change, that doesn't
> give *them* the right to change it - a substantive change must be brought
> back to the WG. So the underlying problem here is not about who has control
> but about the fact that implementing on the run almost guarantees that your
> implementation will be out of date when the thing is finalised. That really
> is not specific to yang, or to the IETF, or to networking.
> 
> (In 1925, public electricity supply in London was at 24 different voltages
> and 10 different frequencies. They didn't wait for the standard to be final
> then, either.)
> 
> It seems to me that declaring snapshots from time to time is about the best
> we can do, accompanied by a strong warning that the final version will be
> different.
> 
>     Brian
>