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)_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
